Version Control Git learning notes (iii)

Then git learns to take notes (ii) to learn, today learn git branch management.

1. Create a merge branch

The git directory created by default has only one branch of master, and now we create the Dev branch and switch to the dev branch:

$ git checkout -b dev

The git checkout command plus the-b parameter means create and switch, equivalent to the following two commands:

$ git branch dev$ git checkout dev

Then, use the GIT branch command to view the current branch:

The git branch command lists all branches, preceded by an * number in front of the current branch.

Then we can commit normally on the dev branch, such as making a change to Readme.txt, plus a line:

newis quick.

Then submit:

Now that the Dev branch's work is done, we can switch back to the master branch:

git checkout master

After switching back to the master branch, and then looking at a Readme.txt file, the content just added is gone! Because that commit is on the dev branch, the commit point of the master Branch at the moment does not change:

In, we merge the work of the Dev branch into the master branch:

$ git merge dev

The git merge command is used to merge the specified branch into the current branch. After merging, and then looking at the contents of the Readme.txt, you can see that the latest commit with the Dev branch is exactly the same.

Taking note of the fast-forward information above, Git tells us that this merger is a "fast-forward mode", which is to direct master to the current commit of Dev, so the merging is very fast.

Of course, not every merger can be fast-forward, and we'll talk about other ways of merging later.

Once the merge is complete, you can safely delete the dev branch:

After deleting, view branch, only the master branch is left:

Because creating, merging, and deleting branches is fast, git encourages you to use branches to accomplish a task, merge and then delete the branch, which works the same as directly on the master branch, but it is more secure.

Summary

<name><name><name><name><name>

2. Conflict resolution

Life is not as good as ten, and merging branches is often not smooth sailing.

Prepare the new Feature1 branch and continue with our new branch development:

Modify the last line of Readme.txt to read:

Commit on the Feature1 branch:

Switch to the Master branch:

Git also automatically prompts us that the current Master branch is more than 1 commits ahead of the remote Master branch.

On the master branch, change the last line of the Readme.txt file to:

Submit:

Now, the master branch and the Feature1 branch each have a new commit, in which case git cannot perform a "quick merge" and can only attempt to merge the changes, but the merge may conflict, so let's try this:

It's a conflict! Git tells us that there is a conflict with the Readme.txt file and must be resolved manually before committing. Git status can also tell us about conflicting files:

We can view the contents of Readme.txt directly:

Git uses <<<<<<<,=======,>>>>>>> to mark the contents of different branches, we modify the following to save:

Re-submit:

You can also see the merging of branches with the git log with parameters:

$gitlog--graph--pretty=oneline--abbrev-commit

Finally, delete the Feature1 branch:

Summary

When git cannot merge branches automatically, you must resolve conflicts first. After resolving the conflict, submit again, and the merge is complete.

You can see the branching merge diagram with the git log–graph command.

3. Branch Management Policy

Typically, when merging branches, GIT uses fast forward mode if possible, but in this mode, the branch information is discarded when the branch is deleted.

If you want to force the fast forward mode to be disabled, GIT will generate a new commit at merge, so you can see the branching information from the branch history.

Let's do some real-–no-ff git merge:

First, you still create and switch the dev branch:

Modify the Readme.txt file and submit a new commit:

Now, we switch back to master:

To prepare to merge the Dev branch, note the –NO-FF parameter, which means that fast forward is disabled:

merge --no-ff -m "merge with no-ff" dev

Because this merge is going to create a new commit, add the-m parameter and write the commit description in.

After merging, we use git log to see the branching history:

$gitlog--graph--pretty=oneline--abbrev-commit

Branching policy

In the actual development, we should follow several basic principles of branch Management:

First of all, the master branch should be very stable, that is, only to release the new version, usually do not work on it;

So where do you work? Work on the Dev branch, that is, the dev branch is unstable, at some point, such as the 1.0 release, then merge the Dev branch to master and release the 1.0 version in the Master branch;

You and your little friends each work on the Dev branch, and everyone has their own branch, and it's time to merge on the Dev branch.

Summary

Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fastforward合并就看不出来曾经做过合并。

4.Bug Branch

In software development, bugs are like the norm. With bugs that need to be fixed, in git, because branches are so powerful, each bug can be repaired by a new temporary branch, repaired, merged, and then removed by the temporary branch.

When you receive a task to fix a bug with a code number of 101, it is natural that you want to create a branch issue-101 to fix it, but, and so on, the work currently being done on Dev has not yet been submitted:

It is not that you do not want to submit, but only half of the work, not submitted, it is expected to be completed in 1 days. However, the bug must be fixed within two hours, what should I do?

Fortunately, Git also provides a stash feature that can "store" the current work site, and then continue to work after resuming the site:

$ git stash

Now, using GIT status to view the workspace is clean (unless you have a file that is not managed by git), so you can safely create a branch to fix the bug.

First determine which branch to fix the bug on, assuming that you need to fix it on the master branch to create a temporary branch from master:

Modify the Readme.txt file, and then submit

After the repair is complete, switch to the master branch and complete the merge, and finally delete the issue-101 branch:

Great, the original two-hour bug fix took only 5 minutes! Now it's time to go back to the dev branch and work!

The work area is clean, where did you save the work site just now? Use the Git stash List command to see:

The work site is still there, git put stash content somewhere, but need to restore, there are two ways:

One is to use git stash apply recovery, but after recovery, stash content is not deleted, you need to use git stash drop to delete;

Another way is to use git stash pop, restore the stash content also deleted:

With Git stash list, you won't see any stash content:

You can stash multiple times, restore the time, first use Git stash list to view, and then restore the specified stash, with the command:

$ git stash apply [email protected]{0}

Summary

pop，回到工作现场。

5.Feature Branch

In software development, there is always an endless amount of new features to add in.

When adding a new feature, you certainly don't want to mess up the main branch because of some experimental code, so every new feature is added, it's best to create a feature branch on top, complete, merge, and finally delete the feature branch.

Now you've got a new mission: Develop a new feature codenamed Vulcan, which is planned for the next generation of starship.

So ready to develop:

After 5 minutes, the development is complete:

Cut back to Dev and prepare to merge:

$ git checkout dev

If everything goes well, the feature branch and the bug branch are similar, merged, and then deleted.

But

At this time, received orders from superiors, due to insufficient funds, the new function must be canceled!

In vain, however, this branch must be destroyed in situ:

Destroy failed. Git friendly reminder, Feature-vulcan branch has not been merged, if deleted, will be lost changes, if you want to forcibly delete, you need to use the command git branch-d feature-vulcan.

Now we forcibly delete:

Summary

<name>强行删除。

6. Multi-person collaboration

When you clone from a remote repository, actually git automatically corresponds to the local master branch and the remote Master Branch, and the default name of the remote Repository is origin.

To view information for a remote library, use git remote:

Or, use git remote-v to display more detailed information:

The address of origin that can be crawled and pushed is shown above. If you do not have push permissions, you cannot see the address of the push.

Push Branch

The push branch is the push of all local commits on that branch to the remote library. When pushing, specify the local branch so that git pushes the branch to the remote branch of the remote library:

$ git push origin master

If you want to push other branches, such as Dev, change to:

$ git push origin dev

However, it is not necessary to push the local branch to the remote, so which branches need to be pushed and which do not?

• The Master branch is the main branch, so synchronize with the remote at all times;

• The Dev Branch is a development branch, and all members of the team need to work on it, so they need to be synchronized with the remote.

• Bug branches are only used to fix bugs locally, there is no need to push remote, unless the boss wants to see how many bugs you have fixed every week;

• Whether or not the feature branch is pushed to the remote depends on whether you are working with your little partner to develop it.

In short, is in git, branch can completely in the local hide to play, whether to push, depending on your mood!

Crawl Branch

When working with multiple people, everyone pushes their own changes to the master and dev branches.

Now, simulate a small partner that you can clone on another computer (note to add SSH key to GitHub) or another directory on the same computer:

When your partner clones from the remote repository, by default, your small partner will only see the local master branch. Do not believe you can use the GIT branch command to see:

Now that your little partner is developing on the dev branch, you must create a remote origin's dev branch locally, and he uses this command to create a local dev branch:

Now he can continue to modify it on Dev, then push the dev branch to the remote from time to moment:

Submit

Your little buddy has pushed his submission to the Origin/dev branch, and you happen to have made changes to the same file and tried to push it:

Push failed because the latest submission from your partner is in conflict with the submission you are trying to push, the workaround is simple, Git has prompted us to grab the latest commit from Origin/dev with git pull, then merge locally, resolve the conflict, and then push:

Merging conflicts, which need to be resolved manually, is exactly the same as resolving conflicts in branch management. After resolving, submit, and then push:

As a result, the working mode of multi-person collaboration is usually this:

1. First, you can try to push your own changes with GIT push Origin branch-name;
2. If the push fails, then because the remote branch is newer than your local, you need to first try to merge with Git pull;
3. If there is a conflict in the merge, resolve the conflict and submit it locally;
4. No conflict or conflict resolution, then GIT push origin branch-name push will be successful!

If Git pull hints "No tracking information", then the link relationship between the local branch and the remote branch is not created, with the command git branch–set-upstream branch-name origin/ Branch-name.

This is a multi-person collaborative mode of work, once familiar with, it is very simple.

Summary:

-v；本地新建的分支如果不推送到远程，对其他人就是不可见的；从本地推送分支，使用git push origin branch-name-b branch-name origin/branch-name--set-upstream branch-name origin/branch-name；从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

Data Link: Git tutorial-branch management

Versioning git Learning Notes (iii)