一个多人开发的Git工作流程，保持干净的历史记录。

Question

Sandofsky主张严格控制“主”存储库的历史记录，保持干净，避免使用分支和检查点提交使其混乱。

引用：

首先使用reset、rebase、squash merges和commit amending等工具清理你的分支，永远不要直接将私有分支合并到公共分支中进行普通合并。将公共历史视为不可变、原子和易于跟踪的，而将私有历史视为可丢弃和可塑造的。

我很赞同这种方法，打算实施一种工作流程，让我的同事们各自拥有自己的远程存储库来推送代码，在他们完成分支工作并清理提交历史后，发起拉取请求。然后我（“集成经理”）将这些干净的提交合并到总开发分支中。

我想这种方法意味着受保护的存储库将没有任何其他分支，除了主分支和开发分支。功能分支只存在于本地存储库中——如果需要在分支上进行协作，可以将该分支推送到其中一位协作者的远程存储库中。

链接1：倡导者 链接2：主分支和开发分支 然而，Pro Git book 将其描述为“公共小项目”的工作流程。这是否意味着在我们的情况下最好使用不同的工作流程，例如将完成的分支推送到受保护的仓库而不是个人仓库？

明确一点：我不想增加不必要的复杂性或开销。我的目标是建立一个工作流程，使我和我的同事能够异步地工作，我可以在他们完成后审查他们的工作，并通过评论或将其合并到代码库中来反弹回去。

---

编辑：显然问题不太清楚，因此我将尝试总结一下：

让我的同事将他们的分支直接推送到我们的仓库是否有劣势（例如会以某种方式“污染”其历史记录）？

- Rijk

---

你能稍微重新表达一下问题吗？它太详细了。请定义“更好”的工作流程。这始终是一种权衡。 - ralphtheninja

Answer 1

我相信 Gitolite 的 "个人" 分支可能非常适合您的需求。这就像拥有一个个人区域（也称为命名空间），每个开发人员都可以（甚至是强制性地）推送。相反，master 对于所有开发人员来说都是只读的，但对于集成者来说则是可写的。

如果 Alice 的 .git/config 包含以下配置：

[remote "origin"]
        url = git@server:project
        push = +refs/heads/*:refs/heads/personal/alice/*
        fetch = +refs/heads/master:refs/remotes/origin/master
        fetch = refs/heads/personal/alice/*:refs/remotes/origin/me/*
        fetch = +refs/heads/personal/bob/*:refs/remotes/origin/bob/*

然后，Alice将会看到：

• 她在服务器上的分支为origin/me/branch
• Bob的分支为origin/bob/branch

这样，Alice可以：

• 在自己的分支上工作，并将其拉取/推送到服务器上
• 从master开始一个新的分支
• 从Bob的分支开始一个新的分支
• 通过简单地将其推送到服务器上来备份自己的工作。

Gitolite可以配置，使得Alice无法写入Bob的个人空间，反之亦然：

@users = alice bob
@integrators = john
@repos = repo1 repo2

repo @repos
    RW+                         = @integrators
    RW+     personal/USER/      = @users

- lorcap

Answer 2

我认为这个工作流程适用于你，没有任何问题：强调公共可能是因为对于公共项目来说，保持干净、不可变的历史记录更加重要。

- Andrew Aylett

---

但是，如果将功能分支放在受保护的存储库中，是否会对开发分支的历史记录产生负面影响（只要在合并之前进行清理）？ - Rijk

Answer 3

一些缺点：

如果有很多开发人员和功能，受保护的存储库将相当快地变得杂乱无章，充满许多分支。如果它只包含例如主和开发，则更加清洁，而不是主、开发、featureA、featureB、featureC等。但是，您始终可以通过在远程上删除它们（git push origin：featureA）来清理存储库，但这会增加额外的清理工作。

此外，当人们从受保护的存储库获取时，他们的存储库将包含对所有这些分支的远程引用，当您删除远程分支时，他们将不得不“git remote prune origin”打开和关闭以清除不再有效的引用，这也增加了额外的工作。

- ralphtheninja

---

谢谢，这样解释清楚了。:) 那么，反过来问一下：我最初描述的设置（每个开发者拥有自己的远程仓库）会有什么缺点呢？我有一种感觉，这可能会引起问题，因为我们在推送到不同的目标。这样做是否会使他们与主要开发线保持同步变得更加麻烦？ - Rijk

我是否错过了一个折中的解决方案？ - Rijk

不这么想。问题是你是否希望人们推送到受保护的存储库，如果不是，他们需要推送到其他地方，这意味着另一层抽象。或者你可以从他们的存储库中拉取，但我们昨天已经讨论过了 :) - ralphtheninja

"一些缺点。然而，这似乎是GitHub团队的运作方式：http://scottchacon.com/2011/08/31/github-flow.html" - Rijk

这是一个权衡的问题...再一次 :) 你想在你的repo中拥有3204938个分支，这样你就可以准确地看到人们正在做什么，还是只想要一个干净的repo，只有主分支和开发分支？这取决于你想要什么。由于我知道你现在只有两个开发人员，我会选择中央repo方案，这是一个微不足道的设置。 - ralphtheninja