GIT Branch Management: Branch management policy, Bug branch, feature branch

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

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

Here's how we do the actual combat --no-ff git merge :

First, you still create and switch dev branches:

$ git checkout-'dev'

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

" Branch Manager "  1file1 insertion (+)

Now, we switch back to master :

' Master '

To prepare the merge dev branch, note --no-ff The parameter, which indicates disabled Fast forward :

" merger with No-ff "  'recursive'11 file  1 insertion (+)

Because this merge will create a new commit, add the -m arguments and write the commit description.

After merging, let's take a git log look at the branching history:

$  git log--graph--pretty=oneline--abbrev-Commit*   7fbc277 merger with no-FF|| * 4c49945 Branch Manager|/*   0f3d64a fixed Conflicts|| * b4309b0 Create new branch FE Ature1 First Modify* | 0b56936 GoBack Master First modify|/* 45ae9a9 Create New branch .... * 90BC1F7 Test name ....

As you can see, no pattern is used Fast forward , and the merge is like this:

Branching policy

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

First, 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? The work is on the dev branch, that dev is, the branch is unstable, to some point, such as the release of 1.0, then the dev branch to merge master , in the master Branch Release 1.0 version;

You and your friends each work on the dev branch, everyone has their own branch, and occasionally merge on the dev branch.

So, the branch of teamwork looks like this:

Summary

The GIT branch is very powerful and should be fully applied in team development.

Merging branches, plus --no-ff parameters can be combined with normal mode, the merged history has branches, you can see that there has been a merger, and the fast forward merger will not be seen to have been merged.

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 001, it is natural that you want to create a branch bug-001 to fix it, but, and so on, the work that is currently in dev progress has not yet been submitted:

 $ git Statuson branch devchanges not staged    commit: (use   " git add <file>..   "    " git checkout-<file> ...    to discard changes in   working directory) Modified:readme.txtno changes added to commit (use   "
      git add   " and/or  " git commit-a  " ) 

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 to "store" the current work site, and then continue to work after resuming the site:

$ git stashsaved working directory and index state WIP on dev:e980635 Devhead are now at e980635 Dev

Now, with the git status view workspace, it's clean (unless you have a file that's 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 master fix it on the branch, from master creating a temporary branch:

' Master '  'origin/master'9  commits.   " git push " to publish your local commits)

$ git checkout-b bug-001'bug-001'

Now fix the bug, you need to change "Git branch manager ..." to "Git branch manager....modify" and then commit:

" Bug Modify " [Bug-0011file11 deletion (-)

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

$ git checkout masterswitched to branch'Master'Your Branch is ahead of'Origin/master'By9commits. ( use"git push"To publish your local commits) $ git merge--no-ff-m"merge bug fix 001"bug-001Merge made by the'Recursive'strategy. Readme.txt|2+-1 fileChanged1Insertion (+),1Deletion (-)

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

' Dev ' $ git Statuson branch devnothing to commits, working directory clean

The work area is clean, where did you save the work site just now? Take a git stash list look at the command:

$ git stash list[email protected]{0}: WIP on dev:e980635 Dev

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 does not delete, you need git stash drop to use to delete;

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

$ git Stash popon branch devchanges not staged forCommit: ( use"git add <file>, ... ."To update what'll be committed) ( use"git checkout--<file>, ... ."To discard changesinchworking directory) Modified:readme.txtno changes added to commit ( use"git add"and/or"git commit-a") Dropped Refs/[email protected]{0} (9BFEED878D4C504CF12C67A6965DB13506567B4A)

git stash listIf you look at it again, you won't see any stash content:

$ git Stash list

You can stash multiple times, restore the time, first with git stash list view, then restore the specified stash, with the command:

$ git stash Apply [email protected]{0}

Summary

When fixing a bug, we will fix it by creating a new bug branch, then merging and finally deleting;

When the work is not finished, first put the job site git stash , and then go to fix the bug, repair, and then git stash pop back to the job site.

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:

$ git checkout-b feature-'feature-vulcan'

After 5 minutes, the development is complete:

$ git add readme.txt$ git statuson branch feature-vulcanchanges to be committed:  "git Reset HEAD <file> " To Unstage)        Modified:   Readme.txt
" Add Feature-vulcan " [Feature-vulcan 939d622] Add feature-1file42 Deletions (-)

Cut back dev , ready to merge:

' 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:

$ git branch-d feature-'feature-vulcan'git branch-d Feature-vulcan'.

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:

$ git branch-d feature-vulcandeleted Branch feature-vulcan (was 939d622).

Summary

To develop a new feature, it is better to create a new branch;

If you want to discard a branch that has not been merged, you can remove it by git branch -D <name> force.

GIT Branch Management: Branch management policy, Bug branch, feature branch