Merge Conflicts

As you’ll recall from the last post, when we tried to cherry-pick our bug fix from the feature branch into the main, Git wasn’t sure what we wanted the finished file to look like and forced us to tell it ourselves. That shouldn’t have happened in the particular situation we dealth with last time, but today, we’ll be looking at situations where we would actually expect that to occur.

Merge Conflicts

When moving code from one branch of a repository to another, a merge conflict occurs when there have been commits to both branches that change the same line of the same file since the last time the branches were synced with each other. In this situation, Git needs to be told which version of that line you want to keep in the final result.

Log into GitHub.com and create a new private repo initialized with a README file. The README will be initialized with a heading containing the name of your new repo. After creating the repo, click the pencil in the top-right corner of the README to edit it.

Add a few lines of code as shown below, and commit the changes directly to the main branch.

Go back to the main page of the repo, click the branch dropdown, and create a new branch called some-feature.

Edit lines 5 and 9 of the README file in the some-feature branch as seen below and commit directly to the some-feature branch.

Now we will simulate changes made by another developer on the project. Switch back to the main branch and edit lines 5 and 9 of the README again, putting different content than what was in the feature-branch version of the file, and commit directly to the main branch.

Go back to the main page of the repo. At the top of the page, you will see a notice that “some-feature had recent pushes <amount of time> ago.” Click the “Compare & pull request” button next to this notice.

This will take us to the pull request creation form. Notice at the top of the screen there is a warning that the merge can’t be done automatically. Add a short description to the pull request and click “Create pull request.”

After creating the pull request, we will again see the warning that the branch we are attempting to merge has conflicts with the main branch that can’t be resolved automatically. Click the “Resolve conflicts” button on the right-hand side of this notice.

This will take us to the conflict resolution view. The start of the conflicted section is marked by <<<<<<< some-feature. This tells us that the lines directly below this are the version of the conflicted file as it appears on the some-feature branch. The end of that version is marked by =======. The end of the conflicted section is marked by >>>>>>> main. This tells us that the lines directly above that are the version of the conflicted file as it appears on the main branch. Note that GitHub.com treats these as a single conflicted section. Other versions of Git repositories would have marked the changes on line 5 and the changes on line 9 as two separate conflicted sections, leaving the unchanged line 7 unmarked.

Now we can manually edit the file to the final version we want to merge onto the main branch. In this particular case, we’ll keep only the version from the some-feature branch. We could also, if we wanted to, keep only the version from the main branch, keep both versions, or manually create a hybrid of the two versions. Delete the lines we don’t want to keep, then remove the conflict markers <<<<<<< some-feature, =======, and >>>>>>> main. This allows Git to recognize when the conflict has been resolved. Click “Mark as resolved” in the top-right corner of the editor. Then click the green “Commit merge” button that appears above the “Mark as resolved” button.

This takes us back to the pull request, where we can now see that there are no conflicts remaining and the merge is able to proceed. To merge our changes, click “Merge pull request,” and then click the “Confirm merge” button that appears.

Comments

Post a Comment

Popular posts from this blog

Cherry-Picking

Image
We’ve now dealt with two ways to move code from one branch of a Git repository to another: merging and rebasing. Both merging and rebasing transfer all of the code currently on the source branch to the destination branch, which is not always desirable. To move only some of the source branch’s code to the destination branch, we use a procedure called cherry-picking . No one found the bug from last week’s program, which doesn’t surprise me since it’s a subtle one. The bug is actually twofold, and both aspects have to do with how the Tkinter GUI toolkit handles modifier keys. The first aspect of the problem is that the keybinding Alt-c is only triggered when the focused window receives a lowercase c . If the user has Caps Lock on, pressing Alt and the C key will send a capital C , and the keybinding will not trigger. Open GitHub Desktop to the add-counter branch of the rcp-demo repository we were working in last week, and open the file helloWorldGUI.py i...
Read more

Our First Repository

Image
If you’ve been following along with the last two posts, you should now have a basic idea of what GitHub is and how it works, and you should also have the infrastructure in place to start using it. Now let’s create our first repository. Open GitHub Desktop and click the blue “Create a tutorial repository…” button at the top of the left-hand column. Then click “Continue” in the dialog box that shows up. You will be prompted to authorize GitHub Desktop to access your GitHub account; as in the previous post, click the green button to authorize. You may need to reenter your GitHub password. You will then be taken to the screen below: The first step when using GitHub is to create a branch . You can see in the toolbar at the top of the window that one branch, main , has already been created for us. This is the default branch for our repo. In a repository containing executable application code, the main branch is usually the most recent stable version of the application. For thi...
Read more

Getting Started

Image
Welcome back! Now that we have a basic overview of what GitHub is, let’s get ready to start using it. In order to do that, we need two things: a GitHub account and the GitHub Desktop client. Let’s handle the account first. Creating a GitHub Account Go to github.com , enter your email address in the box in the middle of the screen, and click the green “Sign up for GitHub” button. Enter a password and click “Continue.” The password must either be at least 15 characters long or be at least 8 characters long and include both a number and a lowercase letter. After clicking “Continue,” you will be prompted to enter a username. The username may contain only letters, numbers, and hyphens, and must not be a username that is already in use by another GitHub user. Click “Continue” again. You will now be asked whether you want to receive email updates and announcments from GitHub. Enter y to receive such updates or n to opt out, ...
Read more