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

Si on me demandait de le faire, je le ferais.
Plusieurs branches dérivées du développement échangent uniquement du code via le développement et ne fusionneront pas les unes avec les autres.

Lorsque chaque branche synchronise la branche de développement, utilisez l'option --rebase pour synchroniser le dernier commit de développement avec la branche de développement, puis fusionnez la branche de développement pour développer à l'aide de l'option --no-ff, conservant ainsi le l'intégrité d'une seule branche. S'engager dans la continuité.

Answer 2

Voici ma situation de test locale, utilisant le mode merge --no-ff pour fusionner

Answer 3

Il est recommandé de se référer à cet article que j'ai relu

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

Par exemple, pour la branche hotfix, vous devez passer à la branche de développement et fusionner à la fin

La branche Hotfix est construite à partir de la branche master et doit être fusionnée dans la branche develop et la branche master peut être nommée comme ceci : hotfix-*

.

Les branches Hotfix sont très similaires aux branches de publication dans une certaine mesure. Elles sont toutes deux destinées à préparer la sortie d'une nouvelle version, et elles sont toutes deux inconnaissables à l'avance. La branche Hotfix est un besoin urgent pour résoudre un bug dans le produit en fonction de l'environnement de production actuel et doit être créée. Lorsqu'une certaine version du produit présente un bug sérieux qui doit être résolu immédiatement, la branche Hotfix doit être construite à partir de la balise correspondant à la version sur la branche master, car cette balise marque la version du produit

Créer une branche de correctif

La branche Hotfix est créée à partir de la branche master. Par exemple, la version 1.2 actuelle du produit en ligne présente des problèmes système dus à un bug côté serveur. Mais il n'est pas fiable d'apporter des modifications dans la branche de développement, nous devons donc créer une branche de correctif et commencer à résoudre le problème :

$ 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(-)

N'oubliez pas de modifier le numéro de version après avoir créé la branche.

Ensuite, résolvez le bug et soumettez-le une ou plusieurs fois.

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

Fin de la branche du correctif

Une fois le travail terminé, le code de bug résolu doit être fusionné dans la branche master, mais il doit également être fusionné dans la branche de développement pour garantir que le bug a été résolu dans la prochaine version. Cela ressemble tellement à une branche de publication.

Tout d'abord, fusionnez et mettez à jour la branche principale, puis marquez-la

$ 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

Remarque : vous pouvez utiliser le paramètre -s ou -u pour définir la signature de votre balise.

Ensuite, fusionnez le code de correction de bug dans la branche de développement

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

Il peut y avoir quelques exceptions ici. Lorsqu'une branche de publication existe, la branche du correctif doit être fusionnée dans la branche de publication, pas dans la branche de développement. Lorsque la mission de la branche release est terminée, le code de correction de bugs fusionné dans la branche release sera finalement fusionné dans la branche develop. (Lorsque la branche de développement a un besoin urgent de résoudre ces bogues et ne peut pas attendre la fin de la branche de publication, vous pouvez fusionner en toute sécurité le code de correction de bugs dans la branche de développement. Ceci est également possible).

Supprimez enfin ces branches temporaires

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