There will come a time when you want to integrate changes from one branch into another. Such an integration is called "merging".
Keeping your commits in the separate context of a branch is a huge help. But there will come a time when you want to integrate changes from one branch into another. For example when you finished developing a feature and want to integrate it into your "production" branch. Or maybe the other way around: you're not yet finished working on your feature, but so many things have happened in the rest of the project in the meantime that you want to integrate these back into your feature branch.
Whatever the scenario may be: such an integration is called "merging" and is done with the "merge" command.
Integrating Branches - Not Individual Commits
When starting a merge, you don't have to (and cannot) pick individual commits that shall be integrated. Instead, you tell Git which branch you want to integrate - and Git will figure out which commits you don't have in your current working branch. Only these commits will then be integrated as a result.
Also, you never have to think long and hard about where these changes end up: The target of such an integration is always your current HEAD branch and, thereby, your working copy.
In Git, performing a merge is easy as pie. It requires just two steps:
(1) Check out the branch that should receive the changes.
(2) Call the "merge" command with the name of the branch that contains the desired changes.
Let's integrate the changes from our "contact-form" branch into "master" by clicking on the "Merge" button in the toolbar and selecting "contact-form" from the list of branches.
After confirming the dialog with the "Merge" button, we'll have another look at the "master" branch's history:
...and notice that our "Add new contact form page" commit was successfully integrated into master!
However, the result of a merge action can't always be displayed that clearly: not always can Git simply add the missing commits on top of the HEAD branch. Often, it will have to combine changes in a new, separate commit called a "merge commit". Think of it like a knot that connects two branches.
You can merge one branch into another as often as you like. Git will again figure out which changes haven't been merged and only consider these.
In some situations, merging will result in one or more "merge conflicts". In such a case, Git wasn't able to combine changes, e.g. because the exact same line was modified in two different ways. You'll then have to decide yourself which content you want. We'll talk about dealing with merge conflicts in detail later in this book.
Get our popular Git Cheat Sheet for free!
You'll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.
As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.
Just like with Tower, our mission with this platform is to help people become better professionals.
That's why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.