git - 我们真的需要在 Git 中分支吗？

Question

我在上我的第一个软件工程课。
这是我们中的任何人第一次在团队中工作并使用 git 和 github。
在类里面我们的老师告诉我们，您通常应该从 master 分支，在完成新功能后，将其 merge 回 master。
这就是我一直在做的。
然而，我组的其他成员没有分支。
他们从 github 上的 master pull 到他们的本地机器，进行编辑，在他们的本地 master 上完成他们的功能，然后推送到 github 上的 master。

我试图说服他们分支，但现在我想到它，我发现它更令人困惑。
有人告诉我，分支的目的是制作代码的副本，而不必担心因意外放置无法运行的代码而破坏主节点。

但是他们的本地master不就是一个分支本身吗？当他们进行编辑时，他们不会更改 github 上的 master，因此其他人可以自由地从 github 中提取工作代码。然后它们 merge ，类似于分支。

我很困惑，如果他们正在做的事情似乎有效，我们为什么要分支？

谢谢!

Answer 1

But isn't their local master really just like a branch itself?

是的!

I'm confused, why should we branch if what they are doing seems to be working?

这取决于您的工作流程。您似乎在描述的是这个工作流程:

Alice 创建一个分支 alice跟踪 master鲍勃发出 bob也跟踪的分支 master . Alice 始终 promise alice并且 Bob 始终 promise bob .然后，当他们对自己的更改感到满意时，他们会 merge 到 master 中。 .

当然，这和 Alice 和 Bob 在他们的本地工作 master 几乎没有任何区别。分支!

当同一个人同时处理多个功能时，通常会出现问题。例如

Alice 正在处理 Feature A Bob 正在处理 Feature B . Alice 完成了一半 Feature A并且在 alice 做了一些提交.然而， Feature A很难实现，所以爱丽丝决定她应该在 Feature C 上工作并在 alice 上做了一些提交.鲍勃完成 Feature B并决定他要解决 Feature A等 pull alice进入 bob .

鲍勃完成后 Feature A他想 merge bob进入 master .然而， bob现在包含 Feature A , Feature B和部分 Feature C ，但是 Feature C还没有准备好 merge !很容易看出，这样的工作流程会导致许多令人困惑的 merge 冲突。

诀窍在于，与其拥有个人分支，不如拥有功能分支。 Alice 应该有一个 Feature A 的分支和 Feature C并且 Bob 应该有一个 Feature B 的分支和 Feature A .这样他们就可以在不同的功能上工作而不会踩到对方的脚趾。