Reference link: https: //www.liaoxuefeng.com/wiki/896043488029600/900388704535136
Generally merge with dev branch
Bug branch
Bug branch is a branch, the branch and he even created earlier is no difference, but in Git, branching is so powerful that when the Bug fix, so every bug can be fixed by a new temporary branch after repair, the combined branch, and then delete the temporary branch. and so
First, determine what you want to fix the bug on the branch , assuming that need masterrepair branch, went from mastercreating a temporary branch:
$ git checkout master Switched 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-101 Switched to a new branch 'issue-101'
Now fix bug, need to "Git is free software ..." changed to "Git is a free software ...", and then submit:
$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
After the repair is complete, switch to the masterbranch, and the completion of the merger, and finally deleted issue-101branches
Save site
Bug branch in use and before the branch is no different, it's still a well-known creation / revision / add / commit / return master / merge / delete bug branch. This is not nothing to talk about.
Special is an unexpected situation when we are ready to create A Bug branch may encounter, is what we are working on the dev branch has not been able to meet the requirements submitted. That is our work area as well as file (using git status to see if there are changes not yet committed). and we create a new branch, when the object of the operation is the content of the current workspace.
$ git status On branch dev Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt
Fortunately, Git also provides a stashfeature that the current work site "store up", and so continue to work after the recovery site:
$ Git stash # This is good Saved working directory and index state WIP on dev: f52c633 add merge
Now, with a git statusview workspace is clean (unless the file has not been Git management), so you can safely create branches to fix the bug.
When the bug fixes better after. Then it is time to return to devthe branch of the work!
$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean
The workspace is clean, just keep working the scene where to go? With the git stash listcommand to see:
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
Still work site, Git stash to exist somewhere in the content, but you need to recover it, there are two options:
First, with the git stash applyrecovery, but the recovery, stash content is not removed, you need git stash dropto delete;
Another way is to use git stash pop, while restoring the contents of the stash also deleted:
$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
Then git stash listview, will not see any of the contents of the stash:
Many times you can stash, recovery time, first with a git stash listview, and then restore the specified stash, use the command:
$ git stash apply stash@{0}
summary
Repair bug, we will fix the bug by creating a new branch, and then merge, delete the last;
When the work at hand is not completed, the first job site git stasha bit, and then go to repair bug, after repair, and then git stash popreturn to the job site.
Feature branch
Reference link: https: //www.liaoxuefeng.com/wiki/896043488029600/900394246995648
This is also another name for branch
When you add a new feature, because you certainly do not want some experimental nature of the code, the main branch messing up, so, each adding a new feature, it is best to create a new feature branch, developed above, after completion of the merger, and finally, remove the feature branch.
Sometimes you may experience some additional circumstances, such as in the new Feature your branch has written to the new features, cut back on your dev branch, we are preparing to merge, when suddenly say that this feature receipt of the request to cancel , even if written, although white did, but this branch or that contain confidential information must be destroyed in situ:
$ git branch -d feature-vulcan error: 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-vulcanthe branch has not been consolidated, if you delete, you will lose out modification, if you want to forcibly remove, need to use uppercase -Dparameter. .
Now we are forcibly removed:
$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e).
summary
The development of a new feature, the best to create a new branch;
If you want to discard a branch had not merged, it can git branch -D <name>forcibly remove.