➕Git+

Spring 2024 | Vin Bui

In the course, we only utilized some basic functionalities of Git such as staging, committing, and pushing. However, Git is a lot more powerful than that which we will discuss in this chapter.

Branches

In the course, we mainly focused on one working branch known as main or master. When we made commits, we typically pushed them all into this one branch. When using this approach, collaborating with others was very difficult to do. If we did not fetch and pull from the main branch before working, we often had to deal with merge conflicts. Now, imagine if both developers are working on the same branch concurrently — a merge conflict is very likely to occur.

To avoid having to deal with merge conflicts every time we push to a branch, it’s often better to create separate branches when collaborating. To create a new branch and switch to it, use the following command:

git checkout -b "BRANCH_NAME"

Pull Requests

Pull requests (also known as PRs) allows us to discuss changes that were pushed onto a branch before merging it to the base branch. Let’s look at the following scenario.

Suppose we have a branch called A whose base branch was from main. We push commits and make changes to the branch A like how we would if it was the main branch. When we are ready to push these changes to the main branch, we can submit a pull request through GitHub to merge A to main. This allows other developers to review our code before merging it to the main branch. If changes need to be made, then we can push new commits to our A branch and request a review again.

When should we create a PR? There is no right or wrong answer to this question. A PR can be a single line of code or even a thousand lines. A good rule of thumb is to create a PR if it’s important to the state

PR Chaining

A huge benefit of creating branches and making PRs is that we can chain them together. Say we have two features, A and B, that need to be implemented. We create a branch off of main and call it A. When we are done with making changes to A, we can create a PR to merge it to main.

While the PR is being reviewed, we may need to work on a new feature (in this case feature B). What we can do is create a branch B from A (not main). Now, if we create a PR, we want to create a PR to merge B to A instead of main. This way, we do not have to wait for the previous PR to be reviewed. Additionally, only the changes made between A and B will be shown in the PR, making it a lot easier to review.

When both PRs are approved, we want to merge in the following order:

1. Merge the PR from A to main.

2. Delete the A branch. The target branch in the second PR will automatically change once A gets deleted.

3. Merge the PR from B to main.

Resolving Merge Conflicts

There are times when we may want to merge a working branch into another without creating a PR. For example, if we are on a branch A, we can simply merge main into our branch with the following command:

git merge main

When we run this command, we may receive merge conflicts. In other words, there are conflicts between the changes of the two branches, preventing the merge from happening. My preferred way to resolve merge conflicts is by using GitHub Desktop with Visual Studio Code (VSCode). VSCode will tell us where the conflict is occurring and allow us to resolve it quickly by clicking on “Accept Current Change” or “Accept Incoming Change”. See image below.

Resolving merge conflicts on VSCode.

Of course, we can use our code editor to resolve the merge conflicts, but it can be difficult to locate where exactly the conflict is. GitHub Desktop works seamlessly with VSCode, allowing us to easily pinpoint and resolve the conflicts.

Undoing a Commit

There are times when we may want to undo a commit, such as when we push sensitive information to a public repository. To undo a commit, we can simply use the following command

git reset HEAD~2

where 2 means move backwards by 2 commits (we can replace this with a number of our choice). Note that this is a soft reset meaning that staged files are not reverted back to a previous state. In other words, we keep the code that we wrote on our local repository.

We can then create a new commit and then force push our changes to the repository:

git push --force