Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look.
A line with "=" separates the two conflicting changes.
The contents after the first marker originate from our current working branch. Git was nice enough to mark the problematic area in the file by enclosing it in "> ".
#Github desktop merge conflicts how to
Under the Hood - What a Conflict Looks Likeīefore we look at how to solve these conflicts in Tower, we'll risk a look under the hood: we'll look at the contents of the (currently conflicted) faq.html file in an editor:
index.html was modified in both versions in different ways (the "U" icon in the Status column stands for "unmerged"). box.php was created in both versions, but with different contents. Which is correct - the modification or the deletion? about.html was deleted in one version and modified in the other. In this example, we have three conflicting changes: If you have any merge conflicts, Tower will inform you in a very clear way: E.g.: Did one of your colleagues edit the same file on the same lines as you? Did he delete a file that you modified? Did you both add a file with the same name? When faced with a merge conflict, the first step is to understand what happened. Git will then mark the file as having a conflict - which you'll have to solve before you can continue your work. But if two people changed the same lines in that same file, or if one person decided to delete it while the other person decided to modify it, Git simply cannot know what is correct. Even in this case, Git will most likely be able to figure it out on its own. Most notably, this is when changing the same file. However, there's a handful of situations where you might have to step in and tell Git what to do. You're taking changes from another context (that's what a branch effectively is: a context) and combine them with your current working files.Ī great thing about having Git as your version control system is that it makes merging extremely easy: in most cases, Git will figure out how to integrate new changes. In Git, "merging" is the act of integrating another branch into your current working branch. This is because, in Git, conflicts can only occur on a developer's local machine - and not on the server. It will not bring your complete team to a halt or cripple your central repository. 
As a consequence, Git is able to take care of most things during a merge - leaving you with comparatively simple scenarios to solve.Īlso, a conflict will only ever handicap yourself. One reason for this is that Git, simply stated, works completely different in this regard than Subversion. Subversion you might be traumatized: conflicts in Subversion have the (rightful) reputation of being incredibly complex and nasty. If you're coming from another version control system like e.g. You're always able to undo and start fresh. The first thing that you should keep in mind is that you can always undo a merge and go back to the state before the conflict occurred.
In the course of this chapter, I want to relieve you from this fear. Learn on: Desktop GUI | Command Line Dealing with Merge Conflictsįor a lot of people, merge conflicts are as scary as accidentally formatting their hard drive.
0 kommentar(er)
