Shulou(Shulou.com)05/31 Report--

This article mainly introduces the git branch management methods of what related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe you will have some gains after reading this git branch management method, let's take a look at it.

Branch Management 1 create branches

Use git checkout:

$git checkout-b devSwitched to a new branch 'dev'

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

$git branch dev$ git checkout devSwitched to branch 'dev'

Use git switch:

Create and switch to a new dev branch, you can use:

$git switch-c dev

Note:

Git switch and git checkout are exactly the same for branching operations. Then you can use git branch and git switch as much as possible in the branch operation.

Because git checkout can not only manipulate branches, it can also manipulate files (you can rewrite workspaces).

2 View branches $git branch* dev master3 merge branches

Git merge command: used to merge the specified branch into the current branch.

# switch back to the current branch: $git checkout masterSwitched to branch 'master'# merged to the specified branch: $git merge devUpdating 599dbdb..4aac6c7Fast-forward readme.txt | 1 + 1 file changed, 1 insertion (+)

The Fast forward mode ("fast forward mode") is used above, but in this mode, the branch information is lost after the branch is deleted.

If the Fast forward mode is to be forcibly disabled, Git generates a new commit when merge, so that the branch information can be seen from the branch history.

$git merge-- no-ff-m "merge with no-ff" devMerge made by the 'recursive' strategy. Readme.txt | 1 + 1 file changed, 1 insertion (+) 4 delete branch $git branch-d devDeleted branch dev (was 4aac6c7). Resolve merger conflicts

The conflict occurs as shown in the following figure. Git cannot perform a "quick merge" and must manually resolve the conflict before committing.

1 solve it on the official website of git

Click on the merge request, select the branch content we want, and then select merge.

2 Local solution

Step one. Pull and check the branches for the merge

Git fetch origingit checkout-b "feature1"origin/feature1"

Step two. View and make changes locally

Git marks the content of different branches, such as the following:

Git is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files. > feature1

Step three. Merge branches and resolve conflicts

Git fetch origingit checkout "master" git merge-no-ff "feature1"

Step four. Push code and merge

Git push origin "master"

Other methods are:

Law 1:

Keep the latest local changes and pull the code from the warehouse to the local

Git stash git pull origin master git stash pop

Law 2:

Give up the local code, do not want the new changes, return to the previous version, and then pull the replacement code to the local

Git reset-hard git pull origin master # or git fetch-allgit reset-hard origin/master git pull branch transfer

The purpose of the git cherry-pick command is to apply the specified commit commit to other branches.

$git cherry-pick\

The above command applies the specified commit commitHash to the current branch. This will result in a new commit in the current branch, although their hashes will be different.

For example, the code repository has two branches, master and feature.

A-b-c-d Master\\ e-f-g Feature

Now apply the commit f to the master branch.

\ # switch to master branch $git checkout master\ # Cherry pick operation $git cherry-pick f

After the above operation is completed, the code base looks like the following.

A-b-c-d-f Master\\ e-f-g Feature

As you can see above, a commit f is added to the end of the master branch.

The parameters of the git cherry-pick command are not necessarily the submitted hash value, and the branch name is also possible, indicating the transfer of the latest submission of the branch.

$git cherry-pick feature

The above code indicates that the most recent commit of the feature branch is transferred to the current branch.

Cherry pick supports transferring more than one submission at a time.

$git cherry-pick\\

The above command applies two commits An and B to the current branch. This generates two corresponding new commits in the current branch.

If you want to transfer a series of consecutive submissions, you can use the following simple syntax.

$git cherry-pick A. B

The above command transfers all submissions from A to B. They must be placed in the correct order: commit A must be earlier than commit B, or the command will fail without reporting an error.

Note that using the above command, submit A will not be included in the Cherry pick. If you want to include commit A, you can use the following syntax.

The common configuration items of the $git cherry-pick A ^.. B`git cherry- pick` command are as follows. #-eQuery Mushidit opens an external editor and edits the submission information. #-the commit only updates the workspace and staging area and does not generate new commits. #-x append a line ``cherry picked from commit... `to the end of the submission information to make it easier to find out how the submission was generated later. #-the operator's signature is appended to the end of the submission message, indicating who did the operation. #-m parent-number,--mainline parent-number if the original submission is a merge node that comes from the merge of two branches, then `Pickle will fail by default because it does not know which branch's code change should be adopted. The `- m` configuration item tells Git which branch changes should be adopted. Its parameter ``parent- number'is an integer starting at 1 that represents the parent branch number of the original submission. ````bash$ git cherry-pick-m 1\

The above command indicates that Cherry pick takes the change that commits commitHash from the parent branch of number 1.

Generally speaking, the No. 1 parent branch is the branch that accepts the change, and the No. 2 parent branch is the branch that serves as the source of the change.

If a code conflict occurs during the operation, Cherry pick stops and lets the user decide how to proceed.

(1)-continue

After the user has resolved the code conflict, the first step is to add the modified file back to the staging area (git add.), and the second step is to use the following command to let the Cherry pick process continue.

$git cherry-pick-continue

(2)-abort

After a code conflict occurs, discard the merge and return to the way it was before the operation.

(3)-quit

Exit Cherry pick after a code conflict, but do not return to the way it was before the operation.

Cherry pick also supports transferring the submission of another code base by first adding the library as a remote repository.

Transfer the submission of another code base

$git remote add target git://gitUrl

The above command adds a remote repository target.

Then, grab the remote code locally.

$git fetch target

The above command crawls the remote code repository locally.

Next, check the submission to be transferred from the remote warehouse to get its hash.

$git log target/master

Finally, transfer the submission using the git cherry-pick command.

$git cherry-pick\ commonly used branches

In actual development, we should follow several basic principles for branch management:

First of all, the master branch should be very stable, that is, it is only used to release new versions, and you can't work on it.

Second, the work is all on the dev branch, that is, the dev branch is unstable. At some point, such as when version 1.0 is released, merge the dev branch into master and release version 1.0 on the master branch.

My friends, everyone works on the dev branch, and everyone has his own branch, so it's OK to merge on the dev branch from time to time.

1 bug branch

In the development process, bug is like a common occurrence. With bug, you need to fix it. In Git, because branches are so powerful, each bug can be repaired with a new temporary branch. After repair, the branches are merged, and then the temporary branches are deleted.

When you are given a task to fix a bug with code code 101, it is natural that you want to create a branch issue-101 to fix it, but, wait, the work currently being done on dev has not been submitted:

$git statusOn branch devChanges to be committed: (use "git reset HEAD\..." To unstage) new file: hello.pyChanges not staged for commit: (use "git add\..." To update what will be committed) (use "git checkout--\..." To discard changes in working directory) modified: readme.txt

It is not that you do not want to submit, but that the work is only halfway through and cannot be submitted yet, and it is estimated that it will take another day to complete. However, what if the bug must be repaired within two hours?

Fortunately, Git also provides a stash feature that can "store" the current work site and continue to work later when the site is restored:

$git stashSaved working directory and index state WIP on dev: f52c633 add merge

Now, viewing the workspace with git status is clean (unless there are no files managed by Git), so you can safely create branches to repair bug.

First determine on which branch you want to repair bug, and if you need to fix it on the master branch, create a temporary branch from master:

$git checkout masterSwitched to branch 'master'Your branch is ahead of' origin/master' by 6 commits. (use "git push" to publish your local commits) $git checkout-b issue-101Switched to a new branch 'issue-101'

Now to fix bug, you need to put "Git is free software..." Change it to "Git is a free software..." And then submit:

$git add readme.txt $git commit-m "fix bug 101" [issue-101 8842ff5] fix bug 101 1 file changed, 1 insertion (+), 1 deletion (-)

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

$git switch masterSwitched to branch 'master'Your branch is ahead of' origin/master' by 6 commits. (use "git push" to publish your local commits) $git merge-- no-ff-m "merged bug fix 101" issue-101Merge made by the 'recursive' strategy. Readme.txt | 2 +-1 file changed, 1 insertion (+), 1 deletion (-)

Great! the two-hour bug repair took only 5 minutes! Now it's time to get back to work on the dev branch!

$git switch devSwitched to branch 'dev'$ git statusOn branch devnothing to commit, working tree clean

The work area is clean. Where is the work site just now? Use the git stash list command to see:

$git stash liststash@ {0}: WIP on dev: f52c633 add merge

The work site is still there. Git has stored the stash content somewhere, but it needs to be restored. There are two ways:

First, use git stash apply to restore, but after recovery, the stash content will not be deleted. You need to delete it with git stash drop.

Another way is to use git stash pop to delete the stash content while restoring:

$git stash popOn branch devChanges to be committed: (use "git reset HEAD\..." To unstage) new file: hello.pyChanges not staged for commit: (use "git add\..." To update what will be committed) (use "git checkout--\..." To discard changes in working directory) modified: readme.txtDropped refs/stash@ {0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

If you look at it with git stash list, you won't see any stash content:

$git stash list

You can stash multiple times. When restoring, check it with git stash list, and then restore the specified stash. Use the command:

$git stash apply stash@ {0}

After fixing the bug on the master branch, consider that the dev branch was split from the master branch early, so this bug actually exists on the current dev branch.

So how do you fix the same bug on the dev branch? Repeat the operation once and submit it. There is a simpler way to do this in Git.

For the same bug, to fix it on dev, we just need to "copy" the changes made by the commit of 8842ff5 fix bug 101to the dev branch. Note: we only want to copy the changes made by the 8842ff5 fix bug 101commit, not to merge the entire master branch.

For ease of operation, Git provides a cherry-pick command that allows us to copy a specific submission to the current branch:

$git branch\ * dev master$ git cherry-pick 8842ff5 [dev 0944c8c] fix bug 101 1 file changed, 1 insertion (+), 1 deletion (-)

Git automatically commits to the dev branch. Note that this time the commit commit is 0944c8c, which is different from master's 8842ff5, because the two commit are just the same changes, but they are really two different commit. With git cherry-pick, we do not need to manually repeat the process of repairing bug on the dev branch.

Some smart children's shoes will think, since you can repair the bug on the master branch and "replay" the repair process on the dev branch, can you repair the bug directly on the dev branch and then "replay" on the master branch? Of course, but you still need the git stash command to save the site before you can switch from the dev branch to the master branch.

2 feature branch

In the development process, in addition to bug, there will be endless new features to be added.

When adding a new feature, you certainly do not want to mess up the main branch because of some experimental code, so every time you add a new feature, it is best to create a new feature branch, develop above, complete, merge, and finally, delete the feature branch.

Now you finally have a new task: to develop a new feature codenamed Vulcan, which is planned for the next generation of starships.

So I'm ready to develop:

$git switch-c feature-vulcanSwitched to a new branch 'feature-vulcan'

5 minutes later, the development is complete:

$git add vulcan.md$ git statusOn branch feature-vulcanChanges to be committed: (use "git reset HEAD\..." To unstage) new file: vulcan.md$ git commit-m "add feature vulcan" [feature-vulcan d12cf23] add feature vulcan 1 file changed, 3 insertions (+) create mode 100644 vulcan.md

Switch back to dev and prepare to merge:

$git switch dev

If all goes well, the feature branch and the bug branch are similar, merge and then delete.

But! At this point, I received an order from my superior that the new function must be cancelled due to lack of funds. Although it has been done in vain, the branch containing confidential information must be destroyed on the spot:

$git branch-d feature-vulcanerror: The branch 'feature-vulcan' is not fully merged.If you are sure you want to delete it, run' git branch-D feature-vulcan'.

Destruction failed. Git friendly reminder, feature-vulcan branches have not been merged, if deleted, will lose the modification, if you want to delete forcibly, you need to use the uppercase-D parameter.

Now we forcibly delete:

$git branch-D feature-vulcanDeleted branch feature-vulcan (was d12cf23).

Finally deleted successfully!

This is the end of this article on "what are the methods of git branch management?" Thank you for reading! I believe you all have a certain understanding of the knowledge of "what are the methods of git branch management". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.