多开发者Git工作流，维护干净的历史记录_Git_Workflow

多开发者Git工作流，维护干净的历史记录

git workflow

多开发者Git工作流，维护干净的历史记录,git,workflow,Git,Workflow,Sandofsky对您的“主”回购历史非常严格，保持它的干净，而不会使它与分支和检查点提交混淆您不应该通过普通合并将私有分支直接合并到公共分支。首先，使用重置、重设基础、挤压合并和提交修改等工具清理分支将公共历史视为永恒的、原子的、易于理解的。将个人历史视为可抛弃的、可延展的这对我很有吸引力，我正计划实施一个工作流，在这个工作流中，我的同事每个人都有自己的远程存储库要推送到，并在完成分支的工作并清理提交历史记录后执行拉式请求。随后，我（“集成经理”）将这些干净的提交合并到通用开发分支中我

Sandofsky对您的“主”回购历史非常严格，保持它的干净，而不会使它与分支和检查点提交混淆

您不应该通过普通合并将私有分支直接合并到公共分支。首先，使用重置、重设基础、挤压合并和提交修改等工具清理分支

将公共历史视为永恒的、原子的、易于理解的。将个人历史视为可抛弃的、可延展的

这对我很有吸引力，我正计划实施一个工作流，在这个工作流中，我的同事每个人都有自己的远程存储库要推送到，并在完成分支的工作并清理提交历史记录后执行拉式请求。随后，我（“集成经理”）将这些干净的提交合并到通用开发分支中

我猜这种方法意味着，受祝福的回购协议将不会有任何分支机构，除了。功能分支将只存在于本地存储库中——如果需要在分支上进行协作，可以通过将分支推送到协作员工之一的远程存储库来实现

然而，报告将此描述为“公共小型项目”的工作流。这是否意味着在我们的案例中使用不同的工作流更好，比如将完成的分支推送到受祝福的回购协议，而不是推送到个人存储库

要明确的是：我不想增加不必要的复杂性或开销。我的目标是建立一个工作流程，我和我的同事可以异步工作，我可以在他们完成工作后检查他们的工作，并用注释将其返回，或者在一切正常的情况下将其合并到代码库中

编辑：显然，所问的问题并不清楚，因此我将尝试对其进行总结：

让我的同事将他们的分支机构直接推到我们的神圣存储库中会不会有一个缺点（例如，它会以某种方式“污染”它的历史）？

我看不出这个工作流对您不起作用的原因：强调公共性可能是因为对于公共项目来说，保持一个干净的环境更重要，不可变的历史。

有两个缺点：

幸运的回购协议将很快（取决于有多少开发人员和功能）被许多分支搞得乱七八糟。如果它只包含master和develop，则比master、develop、FeatureUra、featureB、featureC更干净。。然而，您可以通过在远程（git push origin:featureA）上删除回购协议来清理回购协议，但这会增加额外的清理工作

此外，当人们从受祝福的回购协议中获取时，他们的回购协议将包含对所有这些分支的远程引用，当您删除远程分支时，他们将不得不断断续续地“git remote prune origin”以清除不再有效的引用，这也增加了额外的工作量。

我相信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/*

然后爱丽丝就会看到了

她在服务器上的分支为
```
origin/me/branch
```
，以及
Bob的分支为
```
原点/Bob/branch
```

这样，Alice可以：

处理她的分支并将其拉/推至服务器
从
```
master
```
在Bob的分支上新建一个分支
只需按一下服务器就可以备份她的工作

Gitolite可以配置为Alice不能在Bob的个人空间上写字，反之亦然：

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

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

你能把你的问题改一下吗？太精细了。定义“更好”的工作流程。这总是一种权衡。谢谢你，这会让事情变得明朗起来。：）那么，为了扭转这个问题：我最初描述的设置（每个开发人员都有自己的远程存储库）的缺点是什么？不知何故，我觉得这可能会引起问题，因为我们正在向不同的目标推进。这会不会让他们与主开发线保持同步变得更加麻烦？我是否缺少一个中庸的解决方案？我不这么认为。问题是，你是否想让人们推动神圣的回购协议，如果不是，他们需要推动其他东西，这意味着另一层抽象。或者你可以从他们的回购中撤出，但我们昨天讨论过：）“两个缺点”>这似乎是GitHub团队的运作方式，不过：嗯，这是一种权衡。。再说一遍：）你想在回购协议中有3204938个分支机构，这样你就可以准确地看到人们在做什么，还是只想有master和dev分支机构的干净回购协议？这取决于你想要什么。既然我知道你们只是两个开发者，我会选择中央回购方案，这是一个很小的设置。但是，在有福回购中拥有功能分支会对开发分支的历史产生负面影响吗（只要它们在合并前被清理）？