Question

我习惯了Rational Team Concert。我可能正在处理5或6个不相关的代码更改。在RTC中，我只是进行更改，将它们检查到不同的更改集以保持更改分开，但在任何给定时间，我的工作空间都具有来自所有更改集的累积更改。（当然，除非暂停其中一个/一些，但我很少这样做）

在git中，我的理解是，对于每个不相关的更改，我应该有一个单独的分支来进行更改。它们最终会合并回主人或其他主要分支。但我的问题是，如果我一次有5个活动更改，所以5个分支，我想在eclipse中运行累积更改进行调试，然后据我所知，我必须创建一个新分支并合并所有单独的功能分支到它。然后，如果我对5个功能分支中的3个进行更多更改，我必须记住将所有这些更改合并到＆＃34;累积＆＃34;再次分支，以便拥有包含所有最新更改的累积工作文件集。

与我在RTC中的工作流程相比，这看起来非常繁琐....或许我现在对这一切都很错误了......或者可能有一个功能使得这个不那么简单的手动过程？（即一些命令选择一堆分支并用一个动作将它们全部合并到一个新的（或选定的）分支....和/或让累积分支以某种方式知道它应该被同步/从5个功能分支合并，所以我可以告诉它基本上去获取所有这些更改并合并到一个命令中）

有没有人有任何建议？我应该采取不同的方式吗？是否有我需要了解的命令/设置？

谢谢！

Answer 1

我建议不要尝试使用git使用其他工具的工作流程，但要了解如何以自己的方式使用git。

我经常用git做你说的，很容易！确实如此，在git中，您不能过早地将某些未提交的更改标记为属于不同的未来提交。您只能对一次提交执行此操作（使用git add）。但事实证明，很少需要同时构建多个提交。

事实上，您不需要将您的更改分成未提交的提交（git的术语是阶段更改），直到您真正想要的那一刻提交它们。此时，您可以愉快地使用git add（特别是使用非常有用的--patch选项（简称-p））将更改分成有意义的提交。

使用RTC，您将为每个更改集分配一组文件（并可能稍后移动它们），但是当它们没有“＃34;已提交”时，您实际上只有一堆脏文件正在与...合作。使用git，这正是你所做的。你使一堆文件变脏，只有在提交时才决定哪些变化属于一起。

作为一个例子，我经常遇到两种情况，以及我如何处理它们：

情况1：工作中断

处理功能A
意识到你需要修复bug B

鉴于您仍然处于功能A的中间，您可能希望修复B而不使A混淆代码。在那种情况下：

$ git stash
# work on B, test it
$ git add <files>
$ git commit
$ git stash pop

或者，您可能希望修复B而A是半工作。在那种情况下：

# work on B
$ git add -p    # select changes related to B to be committed
$ git commit
# continue working on A

情况2：多项功能

通常，在处理多个功能时，每个功能都使用一个分支。这允许您（1）经常为每个功能提交工作，（2）将每个功能的提交放在一起，以及（3）能够分别为每个功能发送拉取请求。你不能一起测试多个半写功能。

但是，有时您可能实际上同时处理多个简单的事情（每个事务只需要一次提交），或者甚至更频繁地，您可能正在为一个功能进行多项更改，但是为清晰起见，您可能希望将它们分成多个提交。在我的情况下，我几乎总是有调试日志，所以我不想提交，所以我想从调试日志中分离要提交的更改。

在所有这些情况下，解决方案很简单：git add --patch。

# work on multiple things
$ git add -p
$ git commit    # first logical change
$ git add -p
$ git commit    # second logical change
$ git add -p
$ git commit    # third logical change
# you are left with what shouldn't be committed yet

总而言之，在您准备提交某些内容之前，您不需要将更改分成＆＃34;更改集＆＃34;。通常情况下，您可能会因为多种原因触摸同一个文件，因此无论如何您都无法将其置于任何特定的更改集中。想象一下，如果功能A接触文件X和Y，功能B接触文件Y和Z.你在RTC中用Y做什么？

因此，使用git，您所做的是提取需要提交的内容（使用git add --patch，您可以从文件中进行特定更改，可能只提交部分内容）在您需要时进行提交。

与git一样，经常提交并使每个提交尽可能简单（每个提交应标记一个连贯的更改）。这样可以防止你疯狂地尝试分离超过1个月编码的20个功能而不提交任何内容。

Answer 2

是的，你对git的处理方式是正确的。但是，在适应git的行为后，它并不麻烦 - 它只是使每个变化都可追溯。

如果对5个功能分支中的3个进行更多更改，则需要将它们合并到累积分支中。有一些图形化的东西，你会发现哪些分支明显需要合并，下面的任何一个工作：

gitk --all

git log --oneline --decorate --graph --all

如何在git中同时处理许多更改？

2 个答案:

情况1：工作中断

情况2：多项功能