企业中基于Git的源代码管理：建议的工具和实践？ [英] Git-Based Source Control in the Enterprise: Suggested Tools and Practices?
问题描述
我个人项目使用git，认为它很棒。它快速，灵活，功能强大，并且适用于远程开发。
但现在它已经在工作中被授权，坦率地说，我们遇到了问题。 b
$ b
开箱即用，git在大型开发人员（20+开发人员）中集中开发并不适合开发人员具有不同能力和git复杂程度的开发人员 - 尤其是与其他开发人员像Perforce或Subversion这样的源代码控制系统，它们都是针对这种环境的。 （是的，我知道，Linus从来没有打算这么做）。
但是 - 出于政治原因，我们一直坚持使用git，即使它吸收了我们'重新尝试去做。
以下是我们看到的一些内容：
- GUI工具并不成熟
- 使用命令行工具，很容易搞砸一个合并，并抹去其他人的更改。
- 它不提供超出全局只读或读写权限的每用户存储库许可权
- 如果您有权限存储库的任何部分，则可以执行对于存储库的每个部分来说都是一样的东西，所以你不能在中央服务器上做一些其他人无法处理的小型组跟踪分支。
- 工作流程除了一切皆有可能或仁慈的独裁者之外，很难鼓励，更不用说强制执行了。
- 不清楚使用单个大型存储库是否更好让每个人都陷入困境）或大量每个组件的存储库（这使得头痛的尝试同步版本）。
- 对于多个存储库，还不清楚如何复制所有的源其他人从中央资料库拉出来，或者在昨天下午4点半之前做一些事情。
然而，我听说人们在大型开发组织中成功地使用git。
如果您处于这种情况 - 或者您通常有工具，技巧和诀窍，以便在大型组织中使用git更容易和更高效，不是命令行的粉丝 - 我很想听听你有什么建议。
顺便说一句，我已经在LinkedIn上提出了这个问题的一个版本，没有真正的答案，但很多天哪，我也很想知道这一点！
更新：让我澄清...
在我工作的地方，我们不能使用除git之外的其他任何东西。这不是一个选项。我们一直坚持下去。我们不能使用1987年使用过的mercurial，svn，bitkeeper，Visual Source Safe，ClearCase，PVCS，SCCS，RCS，Bazaar，Darcs，单调，Perforce，Fossil，AccuRev，CVS，甚至苹果公司的优秀投影机。因此，欢迎您讨论其他选项，如果您不讨论git，您将无法获得赏金。 ，我正在寻找关于如何在企业中使用git的实用技巧。我在这个问题的顶部列出了一整套我们遇到的问题。再次，人们欢迎讨论理论，但如果你想赚取赏金，给我解决方案。
企业环境中的DVCS vs. CVCS： / strong>
我不会谈论这里的一般优点/缺点，而是专注于您的上下文。普遍的观点是，使用DVCS需要比使用集中式系统更有纪律的团队。这是因为集中式系统为您提供了一种简单的方式来执行工作流程，使用分散式系统需要更多的通信和纪律来坚持已建立的惯例。虽然这可能看起来会导致开销，但我认为增加沟通对于使其成为一个好的流程是必要的。您的团队将需要就代码，变更以及项目状态进行沟通。
在纪律方面的另一个方面是鼓励分支和实验。以下是Martin Fowler最近的bliki条目。）
尽管DVCS提供了很好的合并功能，但是永远不能取代使用Continuous Integration。即使在这一点上，你也拥有很大的灵活性：用于主干回购的CI，用于团队回购的CI，Q& A回购等。
Git企业环境：
Git可能不是您已经指出的企业环境的理想解决方案。重复你的一些担心，我想最明显的是他们是：
-
在Windows上仍然有些不成熟的支持（请纠正我最近改变了）现在Windows有 github windows客户端， tortoisegit ， atlassian的SourceTree - 缺乏成熟的GUI工具，没有一流的公民vdiff / merge工具集成
- 不一致的界面，抽象层次非常低它的内部工作
- svn用户的学习曲线非常陡峭
- Git功能强大，易于修改历史，如果你不知道自己在做什么（即使你认为自己知道你有时会这样做），也是非常危险的。
- 没有商业支持选项可用
我不想在这里启动git vs. hg flamewar，您已经通过切换到DVCS完成了正确的步骤。 Mercurial解决了上面的一些问题，因此我认为它更适合于企业环境：
总之，在企业中使用DVCS时，我认为选择一种引入最少摩擦的工具。为了成功转型，考虑开发者之间的不同技能（关于VCS）尤其重要。
减少摩擦：
好吧，既然你似乎真的陷入了困境，还有两个选择离开了恕我直言。
没有工具可以让git变得更简单; git 很复杂。要么你面对这个问题，要么绕过git： -
- 获得整个团队的git入门课程。这应该只包括基础知识和一些练习（重要！）。
- 将master repo转换为svn并让young-stars git-svn 。这给大多数开发人员提供了一个易于使用的界面，可以弥补团队中缺乏的纪律，而年轻的明星可以继续使用git来进行自己的回购。
说实话，我认为你真的有人问题而不是工具问题。可以做些什么来改善这种情况？
- 您应该清楚地表明您认为您的当前进程将以可维护的代码库。
- 投入一些时间进入持续集成。如上所述，无论您使用哪种VCS，都不会替换CI。你说有些人把垃圾推入主回购：让他们修正他们的垃圾，而红色警报熄灭并责怪他们打破构建（或不符合质量指标或任何其他）。
I use git for personal projects and think it's great. It's fast, flexible, powerful, and works great for remote development.
But now it's mandated at work and, frankly, we're having problems.
Out of the box, git doesn't seem to work well for centralized development in a large (20+ developer) organization with developers of varying abilities and levels of git sophistication - especially compared with other source-control systems like Perforce or Subversion, which are aimed at that kind of environment. (Yes, I know, Linus never intended it for that.)
But - for political reasons - we're stuck with git, even if it sucks for what we're trying to do with it.
Here are some of the things we're seeing:
- The GUI tools aren't mature
- Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes
- It doesn't offer per-user repository permissions beyond global read-only or read-write privileges
- If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.
- Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce
- It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).
- With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.
However, I've heard that people are using git successfully in large development organizations.
If you're in that situation - or if you generally have tools, tips and tricks for making it easier and more productive to use git in a large organization where some folks are not command line fans - I'd love to hear what you have to suggest.
BTW, I've asked a version of this question already on LinkedIn, and got no real answers but lots of "gosh, I'd love to know that too!"
UPDATE: Let me clarify...
Where I work, we can't use ANYTHING other than git. It's not an option. We're stuck with it. We can't use mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, or even Apple's good ol' Projector that I used in 1987. So while you're welcome to discuss other options, you ain't gonna get the bounty if you don't discuss git.
Also, I'm looking for practical tips on how to use git in the enterprise. I put a whole laundry list of problems we're having at the top of this question. Again, people are welcome to discuss theory, but if you want to earn the bounty, give me solutions.
Against the common opinion, I think that using a DVCS is an ideal choice in an enterprise setting because it enables very flexible workflows. I will talk about using a DVCS vs. CVCS first, best-practices and then about git in particular.
DVCS vs. CVCS in an enterprise context:
I wont talk about the general pros/cons here, but rather focus on your context. It is the common conception, that using a DVCS requires a more disciplined team than using a centralized system. This is because a centralized system provides you with an easy way to enforce your workflow, using a decentralized system requires more communication and discipline to stick to the established of conventions. While this may seem like it induces overhead, I see benefit in the increased communication necessary to make it a good process. Your team will need to communicate about code, about changes and about project status in general.
Another dimension in the context of discipline is encouraging branching and experiments. Here's a quote from Martin Fowler's recent bliki entry on Version Control Tools, he has found a very concise description for this phenomenon.
DVCS encourages quick branching for experimentation. You can do branches in Subversion, but the fact that they are visible to all discourages people from opening up a branch for experimental work. Similarly a DVCS encourages check-pointing of work: committing incomplete changes, that may not even compile or pass tests, to your local repository. Again you could do this on a developer branch in Subversion, but the fact that such branches are in the shared space makes people less likely to do so.
DVCS enables flexible workflows because they provide changeset tracking via globally unique identifiers in a directed acyclic graph (DAG) instead of simple textual diffs. This allows them to transparently track the origin and history of a changeset, which can be quite important.
Workflows:
Larry Osterman (a Microsoft dev working on the Windows team) has a great blog post about the workflow they employ at the Windows team. Most notably they have:
- A clean, high quality code only trunk (master repo)
- All development happens on feature branches
- Feature teams have team repos
- They do regularily merge the latest trunk changes into their feature branch (Forward Integrate)
- Complete features must pass several quality gates e.g. review, test coverage, Q&A (repos on their own)
- If a feature is completed and has acceptable quality it is merged into the trunk (Reverse Integrate)
As you can see, having each of these repositories live on their own you can decouple different teams advancing at different paces. Also the possibility to implement a flexible quality gate system distinguishes DVCS from a CVCS. You can solve your permission issues at this level too. Only a handful of people should be allowed access to the master repo. For each level of the hierachy, have a seperate repo with the corresponding access policies. Indeed, this approach can be very flexible on the team level. You should leave it up to each team to decide wether they want to share their team repo among themselves or if they want a more hierachical approach where only the team lead may commit to the team repo.
(The picture is stolen from Joel Spolsky's hginit.com.)
One thing remains to be said at this point though:- even though DVCS provides great merging capabilities, this is never a replacement for using Continuous Integration. Even at that point you have a great deal of flexibility: CI for the trunk repo, CI for team repos, Q&A repos etc.
Git in an enterprise context:
Git is maybe not the ideal solution for an enterprise context as you have already pointed out. Repeating some of your concerns, I think most notably they are:
Still somewhat immature support on Windows (please correct me if that changed recently)Now windows has github windows client , tortoisegit , SourceTree from atlassian- Lack of mature GUI tools, no first class citizen vdiff/merge tool integration
- Inconsistent interface with a very low level of abstractions on top of its inner workings
- A very steep learning curve for svn users
- Git is very powerful and makes it easy to modify history, very dangerous if you don't know what you are doing (and you will sometimes even if you thought you knew)
- No commercial support options available
I don't want to start a git vs. hg flamewar here, you have already done the right step by switching to a DVCS. Mercurial addresses some of the points above and I think it is therefore better suited in an enterprise context:
- All plattforms that run python are supported
- Great GUI tools on all major plattforms (win/linux/OS X), first class merge/vdiff tool integration
- Very consistent interface, easy transition for svn users
- Can do most of the things git can do too, but provides a cleaner abstraction. Dangerous operations are are always explicit. Advanced features are provided via extensions that must explicitly be enabled.
- Commercial support is available from selenic.
In short, when using DVCS in an enterprise I think it's important to choose a tool that introduces the least friction. For the transition to be successful it's especially important to consider the varying skill between developers (in regards to VCS).
Reducing friction:
Ok, since you appear to be really stuck with the situation, there are two options left IMHO. There is no tool to make git less complicated; git is complicated. Either you confront this or work around git:-
- Get a git introductory course for the whole team. This should include the basics only and some exercises (important!).
- Convert the master repo to svn and let the "young-stars" git-svn. This gives most of the developers an easy to use interface and may compensate for the lacking discipline in your team, while the young-stars can continue to use git for their own repos.
To be honest, I think you really have a people problem rather than a tool problem. What can be done to improve upon this situation?
- You should make it clear that you think your current process will end up with a maintainable codebase.
- Invest some time into Continous Integration. As I outlined above, regardless which kind of VCS you use, there's never a replacement for CI. You stated that there are people who push crap into the master repo: Have them fix their crap while a red alert goes off and blames them for breaking the build (or not meeting a quality metric or whatever).
这篇关于企业中基于Git的源代码管理：建议的工具和实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
