正确的git工作流程方案与多个开发人员开展相同的任务 [英] Proper git workflow scheme with multiple developers working on same task
问题描述
我是我们网络开发公司的团队负责人，我想在团队中实施Git工作流程。阅读文档和文章我发现以下结构适合我们：
我们在Bitbucket中有一个存储库。 Master 分支被认为只包含稳定的代码。每个开发者都必须创建他自己的分支，并在他的 own 分支中实现功能/错误修正。一旦他决定，他的代码已经准备好了，他会创建一个很好的分支历史记录（使用rebase，修改，cherry-pick等）并将其推送到Bitbucket，在那里创建一个向master分支的请求。 QA验证功能并批准（或拒绝）它，然后我验证代码，如果它没问题，我将他的工作合并到主服务器中（通过快进或重新分配更好的提交历史记录）。
但是只有在单个开发人员在分支上工作的情况下，这种方案才是好的。在我们的例子中，我们几乎总是有一个分支的两个开发人员，因为一个开发人员正在处理服务器端（PHP）和另一个客户端（HTML / CSS / JS）。这两个应该如何协作，master中的提交历史保持干净？
服务器开发创建HTML文件的基本结构，客户端开发需要获得此结构。从逻辑上来说，服务器开发人员将创建一个分支，并为客户机开发人员创建基于服务器开发分支的自己的分支。但这意味着，服务器开发者需要将他的分支发布到Bitbucket中，这将使他无法重新设置或更改已发布的提交。
>另一个选择是等待，直到服务器dev完成他的工作，发布具有良好提交历史的分支并忘记它，并且只有在该客户端dev开始在该分支中工作之后，这会造成时间延迟，甚至更糟糕。
你如何在你的工作流程中处理这样的协作？
我无法真正说出您的文章中描述的方法的优点，但我可以描述我们如何在工作中使用的工作流程中解决协作编码问题。
我们使用的工作流程是许多分支之一。我们的结构是这样的：
主人是金;只有合并主人才会触及它（稍后会详细介绍）。
开发人员最初从开发者那里获得一个开发分支，即所有开发人员都可以开展工作。我们不是每个开发人员都有一个分支，而是从开发中创建功能或门票分支。
对于每个谨慎的功能（bug，增强等），新的本地分支都是由dev开发的。开发人员不必在同一个分支上工作，因为每个功能分支仅限于该开发人员正在开发的内容。这是git的便宜分支派上用场。
一旦这个功能准备好了，它就会在本地合并回dev，并推送到云端（Bitbucket，Github等）。 ）。每个人都保持同步，经常拉动开发。
我们正在进行每周发布计划，因此每个QA在批准开发分支后都会制作发布分支在名字中加上日期。这是生产中使用的分支，取代了上周的发布分支。
一旦发布分支在生产环境中被QA验证，发布分支就会合并回主dev，为了安全起见）。这是我们唯一一次碰到主人，确保它尽可能干净。
对于我们来说，这对我们来说非常合适，希望它有帮助。祝你好运！
I'm a team leader in our web development company, and I'd like to implement Git workflow in our team. Reading documentation and articles I've found the following structure good for us:
We have a repository in a Bitbucket. Master branch is considered to contain stable code only. Every dev must create his own branch and implement features/bugfixes in his own branch. Once he decides, that his code is ready, he creates a nice branch history (using rebase, amend, cherry-pick etc.) and pushes it to Bitbucket, where creates a pull request to master branch. QA verifies functionality and approves (or disapproves) it, then I'm verifying code and if it is ok, I merge his work into master (by fast-forward or rebasing for better commits history).
But this scheme is good only in a case, when single developer works on a branch. In our case we almost always have two developers for one branch, since one developer is working on server-side (PHP), and another - client-side (HTML/CSS/JS). How these two should collaborate in a way, that commit history in master stays clean?
Server dev creates basic structure of HTML files and client dev needs to get this structure. Logically would be for server dev to create a branch, and for client dev to create his own branch, based on server dev branch. But this means, that server dev needs to publish his branch in Bitbucket, which will make it impossible for him to rebase or change commits, that are already published.
Another option is to wait, until server dev finishes his work, publishes branch with nice commits history and forgets about it, and only after that client dev starts to work in this branch, but this will cause time delays, which is even worse.
How do you handle such a collaboration in your workflows?
I can't really speak to the merits of the methods described in your post, but I can describe how we solved collaborative coding in the workflow we use at work.
The workflow we use is one of many branches. Our structure is thus:
Master is golden; only the merge master touches it (more on this in a bit).
There is a dev branch, taken initially from master, that all devs work off. Instead of having a branch per developer, we make feature, or ticket, branches from dev.
For every discreet feature (bug, enhancement, etc.), a new local branch is made from dev. Developers don't have to work on the same branch, since each feature branch is scoped to only what that single developer is working on. This is where git's cheap branching comes in handy.
Once the feature is ready, it's merged locally back into dev and pushed up to the cloud (Bitbucket, Github, etc.). Everyone keeps in sync by pulling on dev often.
We are on a weekly release schedule, so every week, after QA has approved the dev branch, a release branch is made with the date in the name. That is the branch used in production, replacing last week's release branch.
Once the release branch is verified by QA in production, the release branch is merged back into master (and dev, just to be safe). This is the only time we touch master, ensuring that it is as clean as possible.
This works well for us with a team of 12. Hopefully it's been helpful. Good luck!
这篇关于正确的git工作流程方案与多个开发人员开展相同的任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
