你们在使用git时采用哪些团队工作流程？

Question

你们在使用git时采用哪些团队工作流程？

git

13

我正在将我的团队从TFS转移到GIT，但在这样做之前，我想知道其他人在从像CVS、SVN、TFS等集中式源代码控制转移到像GIT或Mercurial这样的分布式源代码控制系统时可能遇到的任何问题。

一些立即想到的问题是：

每个用户是否在服务器上使用自己的分支进行工作，然后完成后合并，还是只保持本地，完成后推送到服务器？
所有新的开发工作应该在一个分支（例如“next-version”）上进行，还是应该针对“master”进行？
新的开发是否应该在服务器的克隆上进行，然后向生产代码库发出拉取请求，还是生产代码库的分支就足够了？
对第3点的跟进，如果所有内容都在分支上完成，那么有没有办法控制谁可以将其合并到“master”中？
还有什么其他事情是我没有考虑到的，你从集中式版本控制转移到分布式版本控制时发生了什么？

然而，我真正的好奇和问题涉及与GIT和其他分布式源代码控制系统相关的工作流程管理，而不是适合我的当前工作流程的内容。

更新：目前在TFS中的开发流程是我们有一个主文件夹，然后是下一个版本的分支文件夹，当下一个版本的代码完成后，它会合并回主文件夹。团队中的每个成员都拥有整个项目的完全提交权限。我们没有任何复杂的过程，迄今为止，我们使用我们的源代码控制只是作为一个简单的存储库。

然而，这就是为什么我正在寻找更理想的工作流程过程，而不是适合我的当前工作流程的内容。这就是我将问题命名为“关于GIT，你们使用的团队工作流程是什么？”的原因。

- Nick Berardi

1

在#4，看一下gitolite。它提供了细粒度的访问控制。 - bstpierre

4个回答

4

请注意，我没有在公司环境下使用Git，以下答案基于我在使用Git的OSS项目中的经验和对Git的理解。

另请参见gitworkflows(7)手册。

在任何分布式版本控制系统中，以及使用DVCS的任何工作流程中，每个用户都有自己的私有非裸库，用于进行工作。通常的做法是，用户在准备好后再发布他/她的工作。

发布自己的工作可能意味着推送到某个中央库，也可以意味着推送到自己的公共库；从这个开发者的公共库中，维护者（或等效人员）可以拉取更改。

请查看Scott Chacon所著的CC许可书籍《Pro Git. Proffesional Version Control》的第5.1章：分布式工作流程，其中有关于可能工作流程的详细说明（附有图表！）。

所有新开发工作都应该在一个分支上完成（例如“下一版本”），还是应该针对“主分支”进行开发？

推荐的工作流程（但不是唯一可能的）是在单独的分支上开发每个单独的功能，即所谓的功能分支。当功能被认为准备就绪时，它会合并到“下一版本”（开发分支）或“主分支”（稳定分支）中。

[...]

在从集中式版本控制转向分布式版本控制的过程中，我还需要担心其他我没有考虑到的事情吗？

如果您有大型且经常更改的二进制文件，那么使用分布式版本控制系统可能会更难设置；此时集中式版本控制系统可能更好。

- Jakub Narębski

2

我在我们的组织中采用了以下工作流程：http://nvie.com/posts/a-successful-git-branching-model/

我们通过gitolite设置了谁可以对哪个分支进行管理。

这是一个很好的“尾灯”，可以帮助您穿越迷雾。Git给您提供了无数的选项，很难为自己做出工作流决策。从这个开始并适应它。它对我们非常有效。我们正在使用具有OSS风味（NHibernate等）的.NET堆栈。

- Adam Dymitruk

0

Git会根据你的需求进行塑造，而不是像中央源代码控制系统一样让你去适应它。

如果您告诉我们如何管理您的开发和发布过程，我们可以告诉您GIT中哪种工作流适合您。

编辑：关于更新，您可以轻松地在Git中执行此工作流。问题是您从源代码管理工具中想要更多什么。只是因为我们想要改变而进行更改并不是一个好主意。

- Šimon Tóth

我正在寻找更理想的工作流程，而不是适合当前工作流程的东西。这就是为什么我将问题命名为“关于GIT，你使用什么团队工作流程？”我知道从正文中并不清楚，所以我稍作更新。 - Nick Berardi

1

@Nick，我只是想指出，没有所谓的理想工作流程。这里提供的任何工作流程都要么是完全通用的（基本上用简单的“是”回答你所有的问题），要么是为特定的团队/工作流程/流程量身定制的... - Šimon Tóth

@Nick，我建议你从一些简单而相对通用的东西开始。监控哪些方面有效，哪些方面无效，并修改你的工作流以修复那些表现不佳的部分。 - bstpierre

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- wilhelmtell · Accepted Answer

从您的问题中，我感觉您的思维方式仍然停留在集中式版本控制系统上。在分布式系统中，服务器不再是“工作场所”，而只是集体工作的镜像。因此，它甚至不是严格必要的。

通常，中央存储库除了主分支和发布标签外，什么都没有。它应该只反映每个人的共同点。在分布式系统中，分支非常私密，因此应该保持本地。

在我的私人存储库中，我有以下分支：

- master是中央master的精确反映。我从不提交到它。相反，我只从中央镜像拉取到我的master。 - develop-* 是一组特性（工作）分支，从release分支分支出来。例如，我可能会有一个名为develop-foo_performance的分支，其中我调整类Foo的性能。或者，我可能会有一个名为develop-cosmetics的分支，其中我积累了一些次要的美容提交。这些分支大多是针对非常具体的任务的短期分支。这些是草稿分支；我在这里提交所有时间，自由书写提交消息，而不考虑“这个更改是否值得提交”的想法。这是我的私人错误隐藏历史跟踪Ctrl-S。 - release是我将提交压缩成可发布状态的分支。当我完成了针对develop-foo_performance分支上Foo性能调整的具体想法的编码时，我可能会有一组无组织的提交，在各个方向进行实验。我将这些提交变基到release分支中，将它们压缩成逻辑特性导向的提交 - 通常是单个提交。这个压缩扔掉了所有没有最终状态的代码，所以release显示的历史非常干净和线性；所有的实验都消失了，就好像我是一个完美的开发者，可以看到未来，从不犯错误，并拥有令人惊叹的描述性提交。在一天结束时，我将我的release分支推送到中央镜像，然后获取远程master并将其合并到我的master中。 - napkin是我的个人笔记分支。它的根提交与master不同。我从不将此分支合并或变基到任何其他分支中，从不将其推送或拉入其中，也不将任何东西合并到此分支中。在这里，我存储我的待办事项文件、我发现的错误、我的个人笔记、想法、思考问题或任何其他自由书写的文档。它是一个不连续的分支，是我个人处理事情的方式：没有人会看到它。它让我保持组织和清晰。

无论是在工作还是家庭项目中，我只创建新的“develop-*”分支并删除完成和失败的分支。其他分支永远不会消失也不会变基。请注意，当我将远程“master”合并到我的“master”时，合并应该是快进的。这是因为我从不提交到自己的“master” - 只拉到它。

此工作流支持集成开发人员;负责将其他人的工作集成到中央“master”分支的开发人员。如果人们从未提交到他们的个人“master”分支，则他们保证其个人“master”与生产代码库完全相同。这是一种安全网，所以人们可以始终从中分支出，如果他们需要一个干净的代码库。

如果两个开发人员想共享实验，则可以互相发送拉取请求，或通过“git format-patch”通过电子邮件发送提交。这是最好的分布式工作方式：通信在同等级别之间进行，不关心实验的人不必看到它。他们保持专注，对于他们来说，项目看起来更小、更简单。