Practice about git-flow

There are many doubts about the use of git, so I wrote an article to record it.

Overview

As shown in the figure below, it is a common git work strategy, which is basically said on the Internet.

The main concept is that when there is a feature, pull an independent branch on the develop to do it, and a branch corresponds to a feature. After the completion, go to the develop in merge/rebase. When the version is to be released, it is extracted from the develop to the release branch. (Some teams in this part are different. They will first pull the stable version of develop to master and then pull from master when releasing).

The overall concept is very simple, and there are many auxiliary tools to help implement this strategy. But when bringing new people, they always encounter similar problems, mainly because GIT is not familiar with it.

Get started

normal flow

1) The master adds an initial file 1.txt, and then pushes it to the remote

2) After successful push, add branch -> develop

git checkout -b develop



The current branch status is just a little bit. In order to see it more clearly, a push will be made in develop: a 2.txt file will be added, and a line of content will be added to the 1.txt file.

3) The new feature
is now to develop a new requirement, we first pull a branch based on develop

git checkout -b feature/1

Then add something to 1.txt. The current content of 1.txt is as follows:

master - Hello World
develop - My Baby
feature/1 - Test

commit

4) Add a second feature
In order to imitate collaborative development, we re-pull a source code based on the develop branch, and then add a second branch: feature/2. Also modify 1.txt:

master - Hello World
develop - My Baby
feature/2 - Test2

Because both features are based on develop and neither is push, feature2 cannot see the content of feature1

5) Both feature1 and 2 have completed the development, after commit and push respectively

It can be seen that forks have begun to appear now. At this time, we need to organize a version in the develop branch and release it to the test server for testing, and rebase the two branches to develop respectively.

5.1) Rebase feature/1 first

Doubtful point: Who rebases who?
This is a question that is often asked when bringing new people. Our principle is to use the later branch to rebase to the earlier branch. You can see that our develop is behind feature/1. , so it is on the develop branch and then rebase feature/2.

develop successfully went to the node of feature/1, there is no conflict, and then rebase feature/2, which is also rebase feature/2 in develop. It can be expected that because both features have changed the same file, there must be conflicts to be dealt with.

master - Hello World
develop - My Baby
<<<<<<< HEAD
feature/2 - Test2
=======
feature/1 - Test
>>>>>>> feature/1 done

Modify 1.txt to the following:

master - Hello World
develop - My Baby
feature/2 - Test2
feature/1 - Test

Then add 1.txt and use git status to check the current status:

mac002:gittest sevens$ git status
rebase in progress; onto 87e2b10
You are currently rebasing branch 'develop' on '87e2b10'.
  (all conflicts fixed: run "git rebase --continue")

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   1.txt

After the file has been modified, continue to rebase with the following command:

mac002:gittest chensh$ git rebase --continue
Applying: feature/1 done

Successfully merged two feature branches

As shown in the figure above, blue is our develop branch. You can see that the codes of feature/1 and feature/2 have been successfully merged into the develop branch, and then push to remote.

Question point: Why does the branch of feature/1 on the figure feel that it is not integrated into the develop?

In fact, this is the difference between rebase and merge. We can go back to feature/1 and perform a merge on the develop to see the effect:
there will also be conflicts to deal with. After resolving the conflicts, commit and get the following branch diagram:

After merging feature/1 is before develop.

So we can see the difference between rebase and merge. Rebase merges the content of the branch into the target branch, but the branch itself will not be merged into the target branch. Therefore, after rebase, we can delete the branch directly. of. And merge is to merge the entire branch into the target branch.

6) Release the beta version

At this time, for clarity, we can add a tag to the current node to record the current version:

You can take it out and put it on the test suit.

7) Release the production version

Going back to our gitflow graph, we need a branch called release. Since it is the first version, it is enough to add a branch directly based on the current develop node.