checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'fixed the broken email address' [hotfix 1fb7853] fixed the broken email address 1 file changed, 2 insertions(+)
git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' [iss53 ad82d7a] finished the new footer [issue 53] 1 file changed, 1 insertion(+)
• It happens when two branches have changed the same part of the same file, and then those branches are merged together. • Git has trouble understanding which change should be used, so it asks you to help out.
special block into the file that contains the contents of both versions where the conflict occurred. <<<<<<< HEAD:index.html <div id="footer">contact : [email protected]</div> ======= <div id="footer"> please contact us at [email protected] </div> >>>>>>> iss53:index.html • The top part (everything above the =======) is the version in HEAD, the branch being merging into (the master branch in our example). • The top part (everything below the =======) is the version in the iss53 branch
either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: <div id="footer"> please contact us at [email protected] </div> • This resolution has a little of each section, and the <<<<<<<, =======, and >>>>>>> lines have been completely removed. • After you’ve resolved each of these sections stage the file to mark it as resolved.
clean before attempting a merge. If you have work in progress, either commit it to a temporary branch or stash it. • This allows you to undo anything you try during the conflict resolution. • If you have unsaved changes in your working directory when you try a merge, getting back to a buildable, working code base isn’t as easy.
human readable. (.pbxproj, .sln, .storyboard) • Situations where a file has lots of complicated conflicts. • Multiple lines where both branches have made changes.
branch being merged into (master in this example). • Then manually add the changes in branch being merged in (project-changes in the example). • Typically you know more about the branch being merged in than the branch being merged into.
being merged in. • Make sure it builds. • Make sure it runs. • Make sure the tests pass. • (If you have them. You do have them right?) • If possible the 2 (or more) developers of each branch should work together to ensure everything works.
conflicts are better and easier to deal with than large conflicts. • Conflicts become more troublesome as branches become more divergent. • In git-flow, a feature branch can become divergent from develop. • eg. new commits on develop after the feature branch was created.
the down-arrow indicating commits to pull from the remote. • Periodically merge develop into your feature branch. • Conflicts will be smaller when compared to leaving the feature to become divergent and then merging into develop.