我在我的第一个软件工程类。 这是我们第一次在团队中工作并使用git和github。 在课堂上，我们的老师告诉我们，在完成新功能后，通常应将主分支出去，并将其合并回主。 这就是我一直在做的事情。 但是我的团队的其他成员没有分支。 他们从github上的主人拉到他们的本地机器上，进行编辑，在他们的本地主人上完成他们的功能，然后在github上推送给主人。我们真的需要在Git中分支吗？
我试图说服他们分支，但现在我想到它，我觉得它更混乱。 我被告知该分支的目的是制作代码的副本，而不用担心无意中将不可运行的代码毁掉。
但是，他们的本地主人是不是真的就像一个分支本身？当他们进行编辑时，他们不会改变github上的主人，所以其他人可以自由地从github中提取工作代码。然后他们合并，类似于一个分支。
我很困惑，为什么我们应该分支，如果他们在做什么似乎在工作？
谢谢！
但是，他们的本地主人是不是真的就像一个分支本身？
是的！
我很困惑，为什么我们应该分支，如果他们在做什么似乎工作？
这取决于您的工作流程。你似乎要描述的是这个工作流程：
Alice创建一个分支alice跟踪master并且Bob做出bob分支，该分支也跟踪master。爱丽丝总是承诺alice和鲍勃总是承诺bob。然后，当他们对自己的变化感到满意时，他们会融入master。
当然，这与Alice和Bob在当地的master分支上工作几乎没有任何区别！
当同一人同时在多个功能上工作时，问题经常出现。例如，
爱丽丝正在从事Feature A，鲍勃正在致力于Feature B。爱丽丝已经完成了Feature A，并且在alice中做了几次提交。然而，Feature A很难实现，所以爱丽丝决定她应该在Feature C上工作，并且在alice上做了一些提交。 Bob完成了Feature B并决定他想要解决Feature A并且因此将alice拉成bob。
在Bob完成Feature A后，他想将bob合并到master中。但是，bob现在包含Feature A,Feature B和部分Feature C，但Feature C尚未准备好合并！很容易看到，像这样的工作流可能会导致许多令人困惑的合并冲突。
诀窍是，而不是有个人分支应该有功能分支机构。 Alice应该有一个分支Feature A和Feature C，Bob应该有一个分支Feature B和Feature A。这样一来，他们都可以在不同的功能上工作，而不会踩在对方的脚趾上。
这个想法是，你有一个主分支代码是稳定和合并。
比方说，我有一个应用程序，以刮擦网站。
我将创建一个名为develop/pulldata的新分支。在这个分支中，我将致力于提取数据。我的一个团队成员可以在数据上运用一些逻辑，所以他可以创建自己的分支开发/应用逻辑。
一旦他有一些提交并且他的代码是稳定的，他可以打开一个pull request来将他的代码合并到master，你可以在github UI中查看它，看看他改变了什么代码并决定是否改变你想合并，或者如果需要更改。
现在，过了一段时间，我的代码完成了，我打开了一个拉取请求，以便我的同事可以查看我的代码并批准或建议更改。这很容易查看，团队中的每个人都知道主分支是稳定的。但是，其他分支不一定是。当他们合并成主人时他们必须是。
保持较短。主人你在机器中拥有的是当地的主人。您将所有更改推送到origin/master服务器。
为什么不鼓励在master分支上工作的主要原因是有几个人在项目中工作，其中一个分支需要成为所有创建分支的共同基础。
例如，你有你想要的蓝牙模块添加到它的产品，然后创建从主分支add_blueetooth当你没有那么合并是掌握。另一个人正在研究wifi，他可以将他的分支合并到主人手中。这只是常见的CVS工作流程，创建分支会导致并行工作。
实际上，git clone取得所有远程分支，它会为你创建一个本地分支，即master。只需键入此命令git branch -a，
git branch -a
* master
remotes/origin/HEAD
他们一些其他的命令，你可以看到自定义g it branch -r远程分支。
您可以检查本地分支机构通过操纵此位置创建的参考。 refs/remotes/origin
在真实的项目中，人们在功能上进行协作，团队成员在合并前检查其他人的代码，人们在同一时间处理不同的功能或修复，功能可以持续很长时间，因此必须保存开发人员的机器等等等。所有这些都可以通过分支和pushng分支到github来实现。 –