saitama-op / merge-conflict

https://lab.github.com/githubtraining/managing-merge-conflicts
MIT License
0 stars 0 forks source link

Second merge: Let's try a conflict #2

Closed github-learning-lab[bot] closed 5 years ago

github-learning-lab[bot] commented 5 years ago

Step 3: Resolve a simple conflict

You may merge a lot of pull requests before you encounter your first merge conflict. That’s because Git is really smart when it comes to merging. Unless you're paying close attention to other branches in your repository, you usually won't know you have a conflict until you create the pull request.

This branch is a great example. In this scenario, two of our friends have been working in this repository. They both created branches, made changes to the _config.yml file, and opened pull requests. One pull request was merged to master without problems, but now the other pull request shows a conflict.

The history of master and this branch look something like this:

deviated branches

However, because this pull request changes the same lines in the _config.yml file, there is a merge conflict.

Let's help our friends resolve this conflict.

:keyboard: Activity: Resolving your first merge conflict

  1. At the bottom of the page in the "This branch has conflicts that must be resolved" section of the Pull Request, click the Resolve conflicts button

  2. Look for the highlighted sections that begins with <<<<<<< update-config and ends with >>>>>>> master. These markers are added by Git to show you the content that is in conflict

  3. Remove the changes made on the master branch by deleting all of the content below the ======= and above >>>>>>> master

  4. Next, remove the merge conflict markers by deleting the following lines:

    <<<<<<< update-config

    master

  5. Optional: If you'd like, you can edit the _config.yml file with your own information. Change any of the lines within the file, even outside of where the markers were. More about this below

  6. With the merge conflict markers removed, click Mark as resolved

  7. Finally, click Commit merge

Sometimes, the best way to resolve a merge conflict is to add content that's different from both branches, or even to combine all of the changes from both branches. This is why Git needs a human to look at the code and make the proper fixes.


Watch below for my response

github-learning-lab[bot] commented 5 years ago

Step 4: Merge the first resolved pull request

You did it, @saitama-op! Nice job resolving that conflict. Most conflicts in your day to day experience should be pretty simple, as in that activity. You may need to discuss the resolution with your peers, but if your team is regularly working together and reviewing pull requests, resolving conflicts is easy.

What just happened?

Resolving a conflict doesn't automatically merge the Pull Request in GitHub. Instead, it stores the resolution of the conflict in a merge commit and allows you and your team to keep working.

To resolve a conflict, GitHub performs what is known as a reverse merge. This means that the changes from the master branch were successfully merged into your update-config branch. If you merged your branch in to master, it would look like this:

merge after conflict

But with a reverse merge, only the update-config branch is updated:

reverse merge after conflict

This allows you to test the resolved code on your branch before you merge it into master. The master branch should be treated as production ready, bug-free code.

:keyboard: Activity: Merge this pull request

Go ahead and merge this pull request now.

I have already approved this pull request, so if you still see "Review required" in the merge view, try refreshing the page.

  1. Click Merge pull request below
  2. Click Confirm merge
  3. Click Delete branch and get ready for your next activity

Watch below for my response

github-learning-lab[bot] commented 5 years ago

Yay! You've solved your first merge conflict.


Go to the next pull request now!