One quick note: we won’t cover using third party tools or applications to handle conflict resolution. First, by hand (old school!) and then using a couple of tools that come with Git. We are going to look at three different ways to handle merge conflicts. Now that we’ve looked at ways we can avoid merge conflicts, let’s walk through how we can deal with them when they, inevitably, occur. This is for safety because sometimes a merge cannot be completely and correctly undone if there are uncommitted changes. I want to reiterate what I said earlier: one important step is ensure that you have committed or stashed all changes in the working tree before you start a merge. This will “abort the current conflict resolution process, and try to reconstruct the pre-merge state”, according to the manual for git-merge command. It is during these times that you will most likely need to abort the merge. Sometimes this is expected (especially if you’re using generated or compiled files), other times you expected a smooth merge but something has changed or went wrong with branch or repository. The most likely scenario is that you end up with a merge conflict that you need to resolve. Sometimes - hopefully not too often - a merge goes unexpectedly terribly. This happens automatically and doesn’t require that you merge manually. Git will fetch the remote repository (origin develop) and then merge it into the local version. One place you’ve might have already used git-merge but maybe haven’t realized it is with git-pull (using the default options). To ensure that you don’t lose any repository history, you should always use the -no-ff option when creating merges.

The default behavior of git-merge is to do a fast-forward merge when it’s possible. If you’re very particular about how your repository history is recorded, this matters a lot. Otherwise, a history of that feature branch could be lost completely. With a non-fast forward merge commit, Git uses the commit to document in develop the commits you made in the feature branch, preserving the true history of the repository. Git creates a commits for the merge that shows the changes and marks the merge. Both my_feature_branch and develop branches have changes in them. We could also refer to this as a typical or normal merge. This merge commit will show in the history the feature branch. If you have changes in the branch you’re merging into ( my_feature_branch -> develop), then Git will create a merge commit showing the merged changes. The other type of merge is a Non-Fast Forward Merge. This creates a linear progression and removes the feature branch from the history. This is often referred to as “resolving as a fast-forward” and Git will just point develop at the latest commit made in the feature branch. Instead, Git simply points HEAD at the last commit in the my_feature_branch. You are merging my_feature_branch into develop and develop is in the same state that it was when you branched off to start my_feature_branch.Īs far as Git is concerned this doesn’t require an actual merge commit. Sometimes - and probably more often than you think, especially if you’re working on a low volume or maintenance only project - the develop branch doesn’t undergo any changes at all while you were making changes on my_feature_branch. When you merge one branch into another two different types of merges are possible: By having your changes you committed before you start a merge, you also remove the chance that you cannot back out of a merge (see Aborting a Merge for more information). Merges can go wrong (resulting in conflicts that you have to resolve) and you want to have as few variables as possible. Commit Changes Firstīefore you attempt a merge, commit any changes you have in the working tree.

Here are a few best practices to keep in mind as you work with git-merge. $ git checkout masterįor a basic overview of the basics of merging, refer to the earlier section on Git Fundamentals. When you’re ready to deploy to production, those changes are merged into the master branch. You use feature branches (based off of develop) to make changes and then merge those changes back into the develop branch. Your develop branch is only used to deploy to staging. Your master branch is only used for deploying to production. Here’s a basic workflow that assume you use a master, develop, and feature branches: If you’re even slightly experienced with using Git or another VCS on projects with a team, you’re probably familiar with it. Git-merge allows you to join together two different histories into one.

Git rebase ours