This is an article written in early ’18 and posted on my blog. But already do not maintain, take to enrich my gold digging account. I hope this article has been of some help. This article mainly explains how to understand git branches correctly, how to merge branches and manage branches

An introduction to branching

You are free to branch in Git. However, before you can use branches effectively, you need to determine the rules for using them.

Here we introduce the rules for the use of the two branches (Merge branch and Topic branch).

The Merge branches

A Merge branch is a branch that is created so that it can be released at any time. It can also be used as a source branch of a Topic branch. It is important to keep the branch in a stable state. If you want to make changes, you usually create a Topic branch first.

The Merge branch, as the source branch, is usually the master branch that we are developing. Meanwhile, we are constantly adding new features and bug fixes during development. In order to keep the master branch stable at all times, We usually create a new branch for development and then merge it into the Master branch when it’s done (we’ll skip the test branch here because it may or may not have one, so if it does, we won’t add it). In this respect, if you use a graphical tool like Sourcetree, you can see that the master is very linear.

Topic branch

Topic branches are branches created for tasks such as developing new features or fixing bugs. To work on multiple tasks simultaneously, create multiple Topic branches.

The Topic branch is created from the stable Merge branch. After completing the task, Merge the Topic branch back into the Merge branch. (Repeat again)

Here’s a little bit more about Stash

Uncommitted changes and newly added files are moved from the original branch to the target branch when they are moved to another branch while remaining in the index area or working tree.

But checkout will fail if the same file is modified in the target branch of checkout. Either commit the change first or use Stash to store the change temporarily and then checkout.

Stash is an area where file changes are temporarily saved. Stash holds changes in the working tree and index that haven’t been committed yet, and you can pull them out later and apply them to the original branch or to other branches.

Explain it in code:

First, suppose I change two files on the Reserve branch, as shown below:

Now, let’s look at what has changed through diff:

At this point, we switch to the master branch:

At this point, we see that the previously clean Master branch has made these two changes multiple times; We can make some minor changes to cityplan.js, and then use Git Checkout Reserve to cut the Reserve branch. You will notice that the original change on the Reserve branch is overwritten by the latest change on the Master branch.

To solve this problem: You can save your changes to the current branch with git Stash. You can also name your changes ‘blablabla’ with git Stash. If you have more than one stash, you can check it with the Git Stash list. You can select a saved change to develop with git Stash apply stash@{n}. The default git Stash apply selects the last save; The git stash drop is the latest save in the stash@{0} place. Git Stash pop is to select the latest save and remove it from the Stash list. Git Stash Clear clears the Stash stack at once

Maybe I don’t want to commit the code right now, but I want to pull the code or modify the stored code. When you want the current pull or modify to merge with your stored code, you have to git add. Put these changes into the staging area and then git Stash pop to complete the merge. If you go directly git Stash pop will tell you that you can’t use it

error: 
Your local changes to the following files would be overwritten by merge:
	xxxx/xxxx/xxx/xxx/xxx.xx
Please commit your changes or stash them before you merge.
Copy the code

And a friendly reminder that you must commit current changes or a staging before merging

Git is also powerful in that it has good warnings and hints, which in most cases you can use to solve problems

Merging of branches

The merge (master) topic branch is merged into the merge (master) branch. There are two ways to merge branches: use merge or rebase. Using these two methods, the history of the merged branch can be quite different.

merge

Using merge a process that merges multiple histories.

As shown in the figure, the Bugfix branch is a new branch based on the Master branch

When you merge the bugfix branch into the master branch, if the master hasn’t changed in the meantime, Git will do something like this: move the master branch to the latest bugfix branch. Such a merger is called a fast-forward merger.

Alternatively, if the master branch is changed in the meantime (and does not change back to the original version), Git will do something like this: merge results in a commit, and the HEAD of the master branch will move to the commit.

Note: When performing a merge, if the Non fast-forward option is set, a new commit and merge will be generated even if a fast-forward merge is possible. After the non fast-forward command is executed, the branch remains unchanged. It’s easy to figure out what’s going on in this branch. As shown in the figure:

rebase

Again, from the master branch:

If we use Rebase for the merge, it looks like this:

First, when we rebase the Bugfix branch to the master branch, the commit history of the Bugfix branch is appended to the master branch, as shown in the following figure:

After rebase, the HEAD position of the master does not change. Therefore, to merge the master branch and the Bugfix branch, we move the master HEAD onto the bugfix HEAD

conclusion

Merge and Rebase are merge branches, but their characteristics are different, but their results are the same.

  • merge

    One-time merge, simple history. Compare the difference between the original submission and the current submission, reflect the new content, and change the content that conflicts. Git pull will merge your code automatically. Git pull will merge your code automatically.

  • rebase

    Step by step, the history is complex. It merges every commit so that you can see every change and write a resolution for every conflict.

Therefore, the general operations in collaborative development are as follows:

Rebase should be used when the topic branch updates the latest code on the master branch frequently to keep up with the current status of the branch. Use the master as the cornerstone of the current branch. There is no conflict if the current theme branch is developed by you alone. (Note: The theme branch is always ahead of the Master branch)

When we merge a topic branch into the master branch, we use the merge.

Here’s a workflow I often use:

Git pull addressName git pull addressName git pull addressName git pull addressName Git checkout reserve git rebase master // Git rebase --continue If you encounter a patch that does not need to be applied, you can ignore it with the following command: git rebase --continue Git rebase --skip If you want to go back to the state before rebase, you can do: Git checkout master git merge reserve git push addressName masterCopy the code

The advantage of this is that the history on the remote trunk is always linear. Everyone resolves conflicts in the local branch, not in the trunk.

The end of the

I think the above mentioned in the usual development is almost all can deal with, about the back version and so on I have in the previous Git operation basis, you can check. If the above description is not clear or wrong, please point out, I will make a new modification to it.