git分支模型的疑问

Question

如上图的一个成功分支模型。

我的疑问就是，在其他一些辅助性分支merge到develop分支之前，develop分支有改变，那么辅助性分支应该merge develop分支，与develop分支保持同步，但是从图上并看不出这个动作。

如果其他辅助性分支需要实时同步develop分支，那么用merge --no-ff，还是直接merge或者rebase呢？

那么这样一来图形是不是会变乱？

---

这是我本地测试的情况，都用的merge --no-ff模式合并

---

目前又遇到一个问题是，同一个分支不同人clone到本地，做开发，然后在push的时候，偶尔会发生一个merge动作，大概是这样的，在本地git push 的时候，提示需要先pull，此时git pull会自动执行一个merge动作，不知道大家遇到过这个问题没？

还有多人开发的时候，大家是不是都自己创建一个branch分支开发，而不是直接在远程的分支上做开发，比如develop是个远程分支，那么多人开发的时候clone到本地，直接在develop上开发，还是git checkout -b local branch开发？
ps:不知道描述清楚没.

Answer 1

If I were asked to do it, I would do it.
Multiple branches branched from develop only exchange code through develop and will not merge with each other.

When each branch synchronizes the develop branch, use the --rebase option to synchronize the latest commit of develop to the development branch, and then merge the development branch back to develop using the --no-ff option, thus maintaining the commits of a single branch. Continuity.

Answer 2

This is my local test situation, using merge --no-ff mode to merge

Answer 3

It is recommended to refer to this article from our proofreading

http://fanyi.jobbole.com/2214/

For example, for the hotfix branch, you need to checkout to the develop branch and merge at the end

The Hotfix branch is built from the master branch and must be merged back into the develop branch and the master branch. The Hotfix branch can be named like this: hotfix-*

Hotfix branches are very similar to release branches to some extent. They are both meant to prepare for the release of a new version, and they are both unknowable in advance. The Hotfix branch is an urgent need to solve a bug in the product based on the current production environment and must be created. When a certain version of the product has a serious bug that needs to be solved immediately, the Hotfix branch needs to be established from the tag corresponding to the version on the master branch, because this tag marks the product version

Create hotfix branch

Hotfix branch is created from the master branch. For example, the current online version 1.2 product has system problems due to a bug on the server side. But making changes in the develop branch is unreliable, so we need to create a hotfix branch and start solving the problem:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to modify the version number after creating the branch.

Then solve the bug and submit it one or more times.

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

End hotfix branch

After completing the work, the resolved bug code needs to be merged back to the master branch, but it also needs to be merged into the develop branch to ensure that the bug has been resolved in the next version. This is so much like a release branch.

First, merge and update the master branch, and then tag it

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

Note: You can use the -s or -u parameter to set the tag signature for your tag.

Next, merge the bugfix code in the develop branch

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

There may be some exceptions here. When a release branch exists, the hotfix branch needs to be merged into the release branch, not the develop branch. When the mission of the release branch is completed, the bugfix code merged back into the release branch will eventually be merged into the develop branch. (When the develop branch urgently needs to solve these bugs and cannot wait until the end of the release branch, you can safely merge the bugfix code into the develop branch. This is also possible).

Finally delete these temporary branches

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).