你如何构建你的Git仓库工作流程？ [英] How are you structuring your Git repository workflow?

问题描述

我们已经看过和观看过有关大型分布式团队使用Git的视频，但那些没有发布的我们这些人以及我们团队其他人员在办公室工作的情况呢？我们应该如何构建我们的仓库和我们的工作流程？

考虑一直使用Subversion或CVS作为单一权限点的传统办公室。当然，这些团队可以各自维护自己的Git存储库，并根据需要在对方之间推/拉，这在很多情况下很快就会变成噩梦。或者，他们可以各自维护自己的存储库，并与称为团队主的单个存储库同步。或者，可能会有工作流程的任何组合与DVCS打开的可能性。

您的团队如何工作？你发现什么是一个有用的工作流程？

解决方案

我喜欢雅虎的方式。用户界面（YUI）团队似乎正在工作。我不是雅虎，也不是我的团队，但他们的git commit日志揭示了他们的流程。

$ b YUI团队拥有一个中央存储库，每个人该团队已提交访问权限。定期在提交到这个仓库之后（可能是在每次推送后，但我不这么认为），构建系统会触发，重建YUI并将新标记的提交推送到github，社区可以在其中分发代码并在其上工作。

我赞成代表项目官方状态的中央资源库。当然，如果我想与同事分享代码，我可以安排他们从我那里拉一个分支，我们可以这样合作。

master版本库也提供了其他优势，例如易于持续集成，因为可以在主存储库上配置推/拉触发器，以启动单元测试和构建系统。它还确保每个人都知道最近的'已知'版本的存储库的位置，因此如果需要构建，发布或测试项目，则可以合理地保证'主'存储库已准备就绪。

Git几乎支持您可以想到的任何工作流程，但即使在一个小团队中，您也不希望存在关于官方存储库是。可能导致的维护噩梦，特别是在您接近发布时，会令人不快。

We've seen and watched the videos on how large distributed teams are using Git, but what about those of us who aren't distributed and who work in the office with the rest of our team? How should we be structuring our repository(ies) and our workflow?

Think about the traditional office which has been using Subversion or CVS as the single point of authority. Certainly these teams could each maintain their own Git repository and push/pull between each other as necessary, which would quickly turn into a nightmare in many situations. Or, they could each maintain their own repository and sync with a single repository that's known as the "master" for the team. Or, there could be any combination of workflows with the possibilities a DVCS opens up.

How does your team work? What have you found to be a useful workflow?

解决方案

I like the way the Yahoo! User Interface (YUI) team appears to be working. I am not at Yahoo, nor am I on that team, but their git commit logs reveal a lot about their process.

The YUI team maintains a central repository where everyone on the team has commit access. Periodically after commits to this repository (it might be after every push, but I don't think so), the build system fires, rebuilds YUI and pushes a newly tagged commit to github, where the community can fork the code and work on it.

I am in favor of the central repository that represents the "official" status of the project. Certainly, if I want to share code with a co-worker, I can arrange for them to pull a branch from me, and we can collaborate that way.

The "master" repository offers other advantages as well, such as ease of continuous integration, as the push/pull triggers can be configured on the 'master' repository to fire off the unit tests and build system. It also ensures that everyone knows where the most recent 'known good' version of the repository is, so that if the project needs to be built, published, or tested, there can be reasonable assurances that the 'master' repository is ready for that.

Git will support almost any workflow you can think of, but even among a small team, you don't want there to be a question about where the 'official' repository is. The maintenance nightmare that could lead to, particularly as you approach a release, would be unpleasant.

这篇关于你如何构建你的Git仓库工作流程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！