在git中进行"临时"提交的最佳方法是什么？

Question

假设我有一个带有两个分支master和dev的项目.我在dev上提交了一系列特殊事件的提交,这些特殊事件曾经测试过并合并到master中.然后在事件结束后我想删除特定于事件的代码.但是,由于添加了事件代码后已经进行了其他提交,因此无法执行git重置.

目前我使用git checkout来检查合并事件之前的文件,然后使用git diff重新添加自事件提交以来所做的更改.这对我来说似乎是一个非常混乱的方法.

有没有人有更好的解决方案在项目中使用临时代码？

编辑:要清楚,需要提交,推送,未提交,推送更改.

Answer 1

掌握并创建分支:git checkout -b special-event,制作/应用您的更改.事件结束后,只需切换回master并放弃/删除分支.

为了继续进行更改,请在master上进行更改并将它们合并到特殊分支中.git checkout master...修改... git checkout special-event; git merge master.

或者,在一次提交中进行所有与特殊事件相关的更改,然后git revert在要将它们推出时使用并指定该提交.

Answer 2

按照我的非专利方法汇总您的提交：

# work on a new branch
git checkout -b event-36
git commit -a -m "all broken dammit"
git commit -a -m "fixed that damn code"
git commit -a -m "almost ready, going to eat lunch"
git commit -a -m "It's done!"

# other people might be working on master in the meantime, so
git checkout master
git checkout -b erasemeImmediately
git merge event-36
git reset --soft master # THE KEY TO THE WHOLE THING: SOFT RESET!
git commit -a -m "Event 36, all code in one commit"

git checkout master
git merge erasemeImmediately

您可以使用 来做到这一点reflog，但是您需要最近的计算机科学学位（即，它很难理解）。

现在你的提交是一个单一的。现在您可以使用恢复或选择没有它的分支的方式。

Answer 3

“临时代码”？在 git 中，我们使用分支来实现这一点。git 中的提交非常轻量级，而分支只是带有少量逻辑的提交的名称（或引用），与其他系统相比是超轻量级的。

微小的逻辑只是引用自动更新到最后一次提交。这几乎就是分支的全部内容。这意味着在 git 中创建和销毁分支是快速、简单甚至安全的，因为没有真正创建或删除任何内容。删除后，您仍然可以通过 commit-id 引用分支头（是的，它仍然存在，直到它被垃圾收集，即使只有在没有其他引用时才会发生这种情况）。

git 中几乎每个命令都将对提交的引用作为参数。git merge 也是如此。您不是在合并分支，而是在合并提交。是的，您输入“git merge”，但同样，分支只是提交的名称。仅此而已。由于您需要的只是将事件的提交分组在一起，因此只需给它们一个名称即可。

所以正确的做法是为该事件创建一个分支。或者可能是两个：“事件主控”和“事件开发”。现在，您在“event-dev”中为事件开发代码。如果您遇到需要在主代码中修复的错误，请隐藏并切换到正常的“dev”分支，编写修复代码并提交。切换回“event-dev”，从“dev”合并，然后弹出存储。继续开发，完成后，提交并测试。如果可以的话，将“event-dev”合并到“event-master”中。这也将包含修复程序。请注意，修复尚未在“master”中。

如果您需要将修复程序合并到“master”中，只需按照通常的方式进行即可，因为修复程序位于“dev”中。

基本上在此设置中您可以：

• 像往常一样开发主要代码：您提交“dev”，测试并合并到“master”；

• 以类似的方式开发事件特定代码：您提交“event-dev”，测试并合并到“event-master”；这只是相同的工作流程；

• 混合两个工作流程；提交并切换分支，或使用 git stash；

• （几乎）自由地合并分支；如果 master 以某种方式更新并且您需要事件的更改，您可以将 'master' 合并到 'event-dev' 中；如果您迫切需要事件的更改并且等不及将它们推入“master”的通常测试周期，您可以将“dev”合并到“event-dev”中。只要合并是干净的，git 就会这样做，也就是说，除非您在两个 -dev 分支中以两种不同的方式更改了同一段代码（这当然是需要处理的特殊情况）；

如果您需要额外的灵活性，请创建更多分支。为了获得超级灵活性，您可以挑选单个提交到分支中，但一般来说我建议不要这样做（只有当您真正知道自己在做什么时才这样做）。

最后，我应该指出这个工作流程在 git 中是非常自然的。实际上，一般来说，在“dev”中开发并在“master”中拉动更改甚至不是最好的。通常为您正在开发的每个功能或模块创建一个 dev 分支，并将这些分支合并到“dev”中。

我认为使用 git 时正确的心态是：“我今天想编码什么？功能 X。好，让我们创建分支‘feature-x’并开始黑客攻击。”。你的那次事件也不例外。

现在，我知道我告诉你的是你从一开始就应该如何做事情，而现在这没有多大帮助。您需要修复您的树，因为 - 看来 - 您将事件的更改与“dev”分支中的正常更改混合在一起。因此，您的问题是如何正确创建仅包含事件更改的“event-dev”，并同时从“dev”中删除它们。

是时候改写历史了。这有多困难，取决于变化的性质。例如，如果所有更改都属于一个目录，事情会更容易。

这就是我会做的（不知道更好）：

• 使用 git log 检查历史记录；

• 找到第一个事件特定更改之前的提交，注意其提交 ID：这是“day-0”提交；

• 创建一个名为“newdev”的分支，指向该提交。在干净的树中执行此操作，即在执行此操作之前提交： git checkout <commit-id> -b newdev;

• 创建“事件开发”： git checkout -b 事件开发；

• 你现在有两个分支都指向“day-0”提交；

• 现在再看一下历史记录（git log dev），你需要跟着它逐次提交；

• 我假设“day-0”之后的每个提交要么是属于主代码的提交，要么是仅属于事件的提交。你要做的就是在正确的分支中挑选它们，如果是主代码，则选择“newdev”；如果是事件代码，则选择“event-dev”；按正确的顺序一次执行一次（从“day-0”到今天）；

• 如果你很幸运，最终在“newdev”中的提交不会依赖于“event-dev”中的提交，反之亦然；你已经完成了；您可能想将当前的 master 和 dev 重命名（保留它们）为 master-old 和 dev-old，然后将 newdev 重命名为 dev，从 dev 创建 master，从 event-dev 创建 event-master，然后就完成了；

• 如果你不太幸运，有时你必须将“newdev”合并到“event-dev”中，因为某些提交取决于主代码中所做的更改，这很好；如果你有勇气，是时候阅读 git rebase 了；但除非必须，否则不要进行变基；

• 或者（更糟糕的是）“newdev”中的一些提交取决于“event-dev”中的更改...哎呀，如果主分支需要它，那么特定于事件的代码实际上并不是那么特定于事件。需要一些合并；

• 或者（坏）一次提交包含两种更改：分而治之（您需要分离更改并将它们应用到正确的分支），这意味着您将提交一分为二；

• 或者其他我现在无法想象的东西，因为我没有足够的关于你的树的细节。

这可能是一阵微风，也可能是一场噩梦。事先检查每个提交（git show，您可以将其视为补丁），决定要做什么（最终不要挑选，只需编辑文件可能会更容易），如果不确定 - 猜猜看 - 创建一个分支，在那里工作，看看会发生什么，如果满意则合并它，否则放弃它并重试。

到目前为止我还没有提到它，但当然你可以复制整个树，包括 git 文件，并在副本上进行 100% 安全的处理。

从一开始就做对是相当容易的。现在就修好了，祝你好运。:)