使用标签与清洁提交

Question

我对git相对较新，并且已经阅读了一些关于正确工作流程的内容，但我对rebase / {{的建议进行了一些努力1}}在推送​​到其他repos之前提交到单个内聚提交（例如squash）。

我的主要问题是我是业余爱好者的程序员（如果我幸运的话，每天1-2小时），这意味着经常需要几天或几周时间才能达到凝聚力功能提交。此外，github是我的备份。所以我的工作流程通常包括1-5个小提交（其中许多是＃34;固定的愚蠢错误＆＃34;品种）每晚，每晚推送一次到github回购。似乎只发布相对干净的提交并使用github作为备份的目标不兼容。

我只是在完成功能或错误修复时添加标签，而不是github我的提交。在我看来，这似乎是一个合理的选择：

• 不会重写历史记录（这似乎是一件坏事）
• 允许您仅通过过滤标记和区分黑白标记来查看重要提交
• 兼容使用另一个git repo（例如rebase）作为＆＃34;完成＆＃34;之间的备份。提交

我已经环顾四周了，但这似乎从来没有被提供作为＆＃34;清理＆＃34;的替代品。提交工作流程我错过了什么吗？

Answer 1

我同意你的说法，重写git历史通常是一件坏事，特别是如果有其他人为你做同一个分支。

为了使用代表已完成功能或相关错误修复集的提交在主分支上维护git历史记录，我建议创建一个范围有限的分支。例如，您对master的前3次提交可能看起来像

• 存根客户端模型和视图
• 将javascript库更新为最新版本
• 错误修复：修复设置页面上的事件委派和呈现差异

上面列表中的第一个提交可能是您可能创建的一个名为siteSetup的分支的一系列提交，您在将其挑选到master之前已重新设置。

此示例分支siteSetup可能具有以下提交

• 存根客户端模型和视图
• 糟糕＆gt;＆gt;
• 修正拼写错误
• 修复另一个错字......叹息

通过使用分支机构，您可以随意“弄乱”＃34;超出您的提交，只要您在将更改提交给master之前重新提交以进行清理。

Answer 2

我要进入一个分支（肢体），并建议正确的做法是避免变基，急切地分支，最重要的是，与--no-ff合并。

这个伟大的 2010 Vincent Driessen blog post 说明了一个与我想象的几乎相符的工作流程。主发布分支保持相当干净，可以轻松检查，但没有重写/丢失历史记录。关键部分是与--no-ff的合并，这使得很容易看出哪些提交是主要提交而不是次要提交。你甚至不必标记。

然后像：

git checkout master
git log --oneline --graph --all --decorate=full
git log --oneline --graph --all --simplify-by-decoration --decorate=full

让您了解对主分支的主要修改是什么。

我仍然对git还不熟悉，但我很难想象rebase / squash在什么情况下应该优于这种方法。