Git branch - new creation and merging of branches

Creation and merging of branches

Let's take a simple example of branch creation and branch merging. You may use a similar workflow in actual work. You will go through the following steps:

  1. Develop a website.
  2. To implement a new user requirement, create a branch.
  3. Work on this branch.

At this time, you suddenly receive a call saying that there is a very serious problem that needs urgent repair. You will handle it as follows:

  1. Switch to your production branch.
  2. Create a new branch for this urgent task and fix it in it.
  3. After the test passes, switch back to the online branch, then merge the patched branch, and finally push the changes to the online branch.
  4. Switch back to the branch where you originally worked and continue working.

New branch

First, let's assume that you are working on your project and have some submissions on the master branch.

Figure 18. A simple submission history

Now, you have decided to solve the problem in the problem tracking system used by your company. To create a new branch and switch to that branch at the same time, you can run a git checkout command with the - b parameter:

$ git checkout -b iss53
Switched to a new branch "iss53"

It is short for the following two commands:

$ git branch iss53
$ git checkout iss53

Figure 19. Create a new branch pointer

You continued to work on #53 issues and made some submissions. In the process, the iss53 branch keeps moving forward because you have detected it (that is, your HEAD pointer points to the iss53 branch)

$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'

Figure 20. iss53 branch moves forward with the progress of work

Now you get that call. There's an urgent problem waiting for you to solve. With Git's help, you don't have to mix this urgent problem with the revision of iss53. You don't need to spend a lot of energy to restore the revision of the 53# problem, then add the revision of the urgent problem, and finally submit the revision to the online branch. All you have to do is switch back to the master branch.

However, before you do this, you should pay attention to the uncommitted changes in your working directory and staging area, which may conflict with the branch you are about to check out, so as to prevent Git from switching to that branch. The best way is to keep it clean before you switch branches. There are some ways to bypass this problem (i.e. staging and commit naming), which we will Storage and cleaning See the introduction of these two commands in. Now, let's assume that you have submitted all your modifications, and then you can switch back to the master branch:

$ git checkout master
Switched to branch 'master'

At this time, your working directory is exactly the same as before you started \53 problems. Now you can concentrate on fixing urgent problems. Remember: when you switch branches, GIT will reset your working directory to look like it was the last time you committed on that branch. Git will automatically add, delete, and modify files to ensure that your working directory is exactly the same as when the branch was last submitted.

Next, you need to fix this urgent problem. Let's set up a hotfix branch and work on it until the problem is solved:

$ git 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(+)

Figure 21. hotfix branch based on master branch

You can run your tests to make sure your changes are correct, and then merge the hotfix branch back to your master branch to deploy online. You can use the git merge command to achieve the above purpose:

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

When merging, you should notice the word "fast forward". Since the submission C4 pointed to by the branch hotfix you want to merge is the direct successor of your submission C2, Git will directly move the pointer forward. In other words, when you try to merge two branches, if you can go down one branch to reach the other, Git will simply push the pointer forward (move the pointer to the right) when merging the two branches, because there are no differences to be resolved in the merge operation in this case - this is called "fast forward".

Now, the latest modification is in the submitted snapshot pointed to by the master branch. You can start publishing the repair.

Figure 22. master is fast forwarded to hotfix

After the solution to this urgent problem is released, you are ready to return to your work before being interrupted. However, you should delete the hotfix branch first because you no longer need it - the master branch has pointed to the same location. You can use the git branch command with the - d option to delete branches:

$ git branch -d hotfix
Deleted branch hotfix (3a0874c).

Now you can switch back to the branch you are working on and continue your work, that is, the branch for #53 problem (iss53 branch).

$ 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(+)

Figure 23. Continue working on the iss53 branch

Your work on the hotfix branch is not included in the iss53 branch. If you need to pull the changes made by hotfix, you can use the git merge master command to merge the master branch into the iss53 branch, or you can wait until the iss53 branch completes its mission and then merge it back into the master branch.

Merging of branches

Assume that your problem has been merged into master #53, and your problem has been corrected. To do this, you need to merge the iss53 branch to the master branch, which is similar to what you did before merging the hotfix branch. You just need to check out the branch you want to merge into, and then run the git merge command:

$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

This looks a little different from when you merged hotfix branches before. In this case, your development history diverges from an earlier place. Because the submission of the master branch is not the direct ancestor of the submission of the iss53 branch, Git has to do some extra work. When this happens, Git will use the snapshot (C4 and C5) pointed by the end of the two branches and the common ancestor (C2) of the two branches to make a simple tripartite merger.

Figure 24. Three snapshots used in a typical merge

Different from pushing the branch pointer forward before, Git takes a new snapshot of the results of the three-party merger and automatically creates a new commit to point to it. This is called a merge submission, and its special feature is that it has more than one parent submission.

Figure 25. One merge submission

Now that your changes have been incorporated, the iss53 branch is no longer needed. Now you can close this task in the task tracking system and delete this branch.

$ git branch -d iss53

Branch merge in case of conflict

Sometimes the merge operation will not be so smooth. If you make different changes to the same part of the same file in two different branches, Git can't merge them cleanly. If your modifications to #53 problems and hotfix branches involve the same place in the same file, a merge conflict will occur when merging them:

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

At this point, GIT makes a merge, but does not automatically create a new merge submission. Git will pause and wait for you to resolve the conflict arising from the merger. You can use the git status command at any time after the merge conflict to view those files that are in the unmerged state because they contain the merge conflict:

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")

Any files to be resolved due to containing merge conflicts will be identified as unmerged. Git will add standard conflict resolution tags to files with conflicts, so that you can open these files with conflicts and resolve them manually. The conflicting file will contain some special sections, which look like the following:

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> iss53:index.html

This indicates that the version indicated by HEAD (that is, the location of your master branch, because you have checked out this branch when running the merge command) is in the upper half of this section (= = = = = =), while the version indicated by iss53 branch is in the lower half of = = = = = =). In order to resolve the conflict, you must choose to use one of the two parts separated by = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =. For example, you can resolve the conflict by replacing this paragraph with the following:

<div id="footer">
please contact us at email.support@github.com
</div>

The above conflict resolution only retains the modification of one branch, and < < < <, =========, and > > > > > > these lines are completely deleted. After you have resolved the conflicts in all files, use the git add command for each file to mark it as resolved. Once these conflicting files are staged, Git marks them as resolved.

If you want to use graphical tools to resolve conflicts, you can run git mergetool, which will launch an appropriate visual merge tool for you and lead you to resolve these conflicts step by step:

$ git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html

Normal merge conflict for 'index.html':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (opendiff):

If you want to use other merge tools than the default tool (Git uses opendiff as the default merge tool here because the author runs the program on Mac), you can see all supported merge tools after the sentence "one of the following tools". Then enter the name of your favorite tool.

NoteIf you need more advanced tools to solve complex merge conflicts, we will Advanced merge Introduce more about branch merging.

After you exit the merge tool, Git will ask if the merge was successful. If you answer yes, Git will stage those files to indicate that the conflict has been resolved: you can run git status again to confirm that all merge conflicts have been resolved:

$ git status
On branch master
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:

    modified:   index.html

If you are satisfied with the result and you are sure that the previously conflicting files have been temporarily saved, you can enter git commit to complete the merge submission. By default, the submitted information looks like this:

Merge branch 'iss53'

Conflicts:
    index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
#	.git/MERGE_HEAD
# and try again.


# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
#	modified:   index.html
#

If you think the above information is insufficient to fully reflect the process of branch merger, you can modify the above information and add some details to help readers who will review the merger in the future, and tell them how you solved the merger conflict and why.

Tags: git github

Posted by nogeekyet on Mon, 02 May 2022 10:29:34 +0300