[ad_1]
To merge a development branch into the current branch, use “git merge dev-branch-name”. If you get conflict warnings about a merge, use “git merge –abort” to break out of it, or edit the affected files and then commit them.
Git uses branches to isolate development streams, to prevent the stable release branch from being polluted. Bringing work from one branch to the main stream means merging the branches. This is how you do it.
What is a merge in Git?
Git was designed to make forking simple and fast. Unlike other version control systems, branching in Git is a trivial matter. Especially in multi-developer projects, branching is one of Git’s main organizational tools.
Branches test new development efforts so that code can be modified or added to without affecting code in other branches, especially the main or main branch. This usually contains the stable version of your code base.
Isolating these changes from your stable code version makes a lot of sense. But sooner or later, the new code will be tested, reviewed, and approved to be pushed into the master branch. At that point, you need to merge your branch into the master branch.
Actually, branches can have sub-branches, so you might be merging your branch with some other branch instead of the master branch. Just remember that merges always take a branch and merge it into a branch. target branch, whatever that branch is. If you want to merge your master branch into another branch, you can even do that too.
Like most actions in Git, you perform merges in your local repository and push them to your remote repository.
Preparing to merge a branch in Git
We have a small development project with a local Git repository and a remote Git repository. We created a branch called “bugfix14” from the “master” branch and worked on a bugfix.
That job is complete and we have tested our code. Everything works as expected. We want to push those changes to the master branch so that our fix will be part of the next version of the software.
There is a bit of preparation to be done before performing the merge. We need to make sure that the target branch (in this case, the “master” branch) and the branch we’re going to merge with it are up to date.
For this we will use the git status domain.
git status
- On the bugfix14 branch: This is our current branch.
- Your branch is up to date with ‘source/bugfixes’: The branch in our local repository has the same commit history as the branch in the remote repository. That means they are identical.
- nothing to commit There are no changes to the staging area that have not been committed.
- clean work tree: There are no unstaged changes to the working directory.
All of that indicates that the branch is up to date and that we can continue. If any of these indicated that there were changes, we would need to organize them, confirm them and send them to the remote. If someone else has worked on these files, we may need to pull their changes from the remote repository.
Reviewing the branch we’re merging into simplifies the merging process. It also allows us to verify that it is up to date. Let’s take a look at the master branch.
git checkout master
git status
We get the same confirmations that the “master” branch is up to date.
RELATED: How to choose the right Git branching and workflow model for your team
Acting on Merge
Before we merge, our commits look like this.
The “bugfix14” branch was forked from the “master” branch. There was a commit to the “master” branch after the “bugfix14” branch was created. There have been a couple of commits on the “bugfix14” branch.
We have made sure that both of our branches are up to date and have verified the “master” branch. We can issue the command to merge the “bugfix14” branch into the “master” branch.
git merge bugfix14
Fusion occurs. The “bugfix14” branch still exists, but now the changes made on that branch have been merged into the “master” branch.
In this case, the merge command performs a three way fusion. There are only two branches, but there are three commits involved. They are the header of any of the branches and a third commit that represents the merge action itself.
To update our remote repository, we can use the git push domain.
git push
Some people prefer to remove the side branches once they have been fused. Others take it upon themselves to preserve them as a record of the true development history of the project.
If you want to delete the branch, you can do so using the git branch command with the -d (delete) options.
git branch -d bugfix14
To delete the branch in the remote repository, use this command:
git push origin --delete bugfix14
You will have a linear commit history, but it will not be the true history.
RELATED: How to delete Git branches in local and remote repositories
Perform a fast forward merge in Git
If you haven’t made any commits on the “master” branch, your history will look like this. It will also look like this if you have modified the base of your development branch so that it is attached to the end of the “master” branch.
Because there are no commits on the “master” branch, to merge the “bugfix15” branch, all Git has to do is point the “master” parent pointer to the latest commit on the “bugfix15” branch.
We can use the usual git merge domain:
git merge bugfix15
That gives us this result.
Which is the same as this:
Which is the same as this:
Git will perform a fast forward merge whenever possible. If the commits on the “master” branch mean that a fast-forward merge is not possible, Git will use a three way fusion.
you can not force a fast-forward merge, after all, may not be possible, but you can declare it to be a fast-forward merge, or nothing at all. There is an option that tells Git to use a fast-forward join if it can, but not to do a three-way join if it can’t. the option is --ff-only (only fast forward combination).
This merges the “bugfix15” branch into the “master” branch, but only if a fast-forward merge is possible.
git merge --ff-only bugfix15
Git will complain and exit if it’s not possible.
git merge --ff-only bugfix16
In this case, there have been commits to the “master” branch, so a fast-forward merge is not possible.
How to resolve merge conflicts in Git
If the same parts of the same file have been changed in both branches, the branches cannot be merged. Human interaction is required to resolve conflicting edits.
Here, we’ve made changes to a file called “rot.c” in a branch called “bugfix17” that we want to merge into the “master” branch. But “rot.c” has also been changed in the “master” branch.
git merge bugfix17
When we try to merge it, we get a warning that there are conflicts. Git lists the files in conflict and tells us that the merge failed. We could go all the way back using the --abort options:
git merge --abort
But solving mergers is not as scary as it seems. Git has done some work to help us. If we edit one of the conflicting files, in our case, we only have one, we will find the conflicting code sections highlighted for us.
Each conflict is delimited by seven characters less than “<<<<<<<” and seven characters greater than “>>>>>>>“, with seven equals signs”=======among them.
- The code about the equal signs is from the branch you are merging in.
- The code under the equals sign is the code for the branch you are trying to join.
You can easily search for one of the seven character sets and jump from one conflict to another through your file. For each conflict, you must choose which set of edits to keep. You need to edit the code you’re rejecting and the seven-character lines that Git has added.
We are going to keep the code from the “bugfix17” branch. After editing, our file looks like this.
Now we can continue with the combination. But note that we use the commit command to do it, not the merge domain.
We commit the change by preparing the file and committing it as usual. We will check the status before final confirmation.
git add rot.c
git status
git commit -m "Merged bugfix17"
The merger is complete. Now we can push this to our remote repository.
RELATED: How to fix, edit, or undo Git commits (change Git history)
Everything merges eventually
All branches should be merged, eventually, so that changes to them are not orphaned and forgotten.
Merging branches is easy, but dealing with conflicts can get tricky in larger, busy teams. Conflict resolution may require input from each developer just to explain what their code does and why they made the changes. You need to understand that, before you can make an informed decision about which editions to keep.
Unfortunately, Git can’t help with that.
RELATED: Should I use a GUI Git client?
[ad_2]
