Git工作流程讨论

Question

　　看了几个git的工作流，感觉都不太符合自己目前的流程。目前我们有三个环境：生产环境、测试环境、本地环境。开发人员在本地开发，push到测试环境，测试人员就在测试环境测试 验收。

　　目前我们只有十几个人的小团队，没有一个具体的版本发布流程，所以也没有到哪天发布什么版本，哪个任务在什么时间完成之类的，每个人的工作更像是在做hotfix，做完一个小功能或者修复一个小bug就直接推送到develop分支，任务指向测试人员去测试环境测试，没问题了 直接把develop合并到master，发布！ 这个流程在人少的时候还可以，人稍微多一点，就牵扯到 我有个功能要上线了 而另一个功能还在测试阶段，master和develop没法合并，只能等测试结束...

　　基于功能分支的模式，好像可以解决上述的问题，切一个分支做功能或者修复bug，合并到develop去测试，测试通过后合并到master，这时候master就可以随时推送到生产环境。但是另一个问题，团队里的成员水平参差不齐，不能让每个人都有权限合并到master，需要有人去review代码，也就是说，合并到master这个操作只能由一个人或几个人去操作而不是全部，然而可能每天产生的分支就有很多，小到修改一行文字可能都是一个分支，手工去合并这些小分支又是一个很大的工作量.这个跟提交pr的方式有点类似，不够高效...

　　有什么方法能让测试人员及时看到你的修改方便测试 ，又能随时随地的！有选择性的！往生产环境合并代码？

Answer 1

C'est très similaire à notre workflow, mais nous avons stipulé une heure précise pour publier la version. Une fois la version publiée, les développeurs développeront sur leurs propres branches, puis lors de la fusion, ils enverront une demande de fusion. au superviseur, et le superviseur l'acceptera, puis testera également le développement. Après le test, s'il n'y a pas de problème, accédez à la branche principale.

Answer 2

Je pense que votre question est normale. Par exemple, si A crée une fonction, il doit la tester lui-même et il n'y a aucun problème avant de pouvoir pousser la branche de développement puis tester si la fonction globale est complète, peu importe qui la publie. cette version, il doit passer par ce processus. S'il y a un code en cours de test lors du développement, mais qu'il y a une correction de bogue urgente à pousser, il existe généralement deux méthodes : l'une consiste à sélectionner le code testé lors du développement et l'autre consiste à utiliser la branche d'urgence.

Answer 3

git Cherry-pick
Cette commande peut fusionner sélectivement les commits. Pour les tests de notification, vous pouvez configurer GitHub pour envoyer automatiquement des e-mails à l'adresse e-mail spécifiée après la fusion.

git cerise-pick