我是第一个软件工程课。 这是我们第一次在团队中工作并使用git和github。 在课堂上，我们的老师告诉我们，在完成新功能后，您通常应该分离主人，将其合并回主人。 这就是我一直在做的事情。 但是，我小组的其他成员没有分支。 他们从github上的master转到他们的本地机器，进行编辑，在他们的本地master上完成他们的功能，然后在github上推送到master。
我试图说服他们分支，但现在我想到了，我发现它更令人困惑。 有人告诉我，分支的目的是制作代码的副本，而不用担心因意外放置不可用的代码而毁掉主人。
但是他们的本地大师真的不像分支吗？当他们进行编辑时，他们不会在github上更改master，因此其他人可以从github中自由地提取代码。然后他们合并，类似于分支。
我很困惑，如果他们正在做的事情似乎有效，我们为什么要分支呢？
谢谢！
答案 0 :(得分：2)
但他们的本地主人真的就像分支本身一样吗？
是的！
我很困惑，如果他们正在做的事情似乎有效，我们为什么要分支呢？
这取决于您的工作流程。您似乎在描述的是这个工作流程：
Alice制作了跟踪alice的分支master，而Bob制作了一个bob分支，该分支也跟踪master。 Alice总是提交alice，Bob总是提交bob。然后当他们对他们的更改感到满意时，他们会合并到master。
当然，与Alice和Bob在当地的master分支机构工作几乎没有任何区别！
当同一个人同时处理多个功能时，通常会出现此问题。例如
Alice正致力于Feature A，Bob正致力于Feature B。 Alice已经用Feature A完成了一半，并在alice中做了一些提交。但是，Feature A很难实现，因此Alice决定她应该在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的分支。通过这种方式，他们都可以处理不同的功能，而不会互相踩踏。
答案 1 :(得分：0)
这个想法是你有一个主分支，代码是稳定和合并的。
让我们说我有一个抓取网站的应用程序。
我将创建一个名为develop / pulldata的新分支。在这个分支中，我将努力提取数据。我的一个团队成员可以在数据上应用一些逻辑，因此他可以创建自己的分支开发/应用逻辑。
一旦他有一些提交并且他的代码稳定，他就可以打开一个拉取请求将他的代码合并到master，你可以在github UI中查看，看看他改变了什么代码并决定你是否想要合并，或者是否需要进行任何更改。
现在，过了一段时间，我的代码完成了，我打开拉取请求掌握，所以我的同事可以查看我的代码并批准或建议更改。它很容易查看，团队中的每个人都知道主分支是稳定的。但是，其他分支并非必须如此。他们必须在他们合并为主人的时候。
答案 2 :(得分：0)
保持简短。掌握你在机器里拥有的是当地的主人。您将所有更改推送到origin/master服务器。
不鼓励在master分支上工作的主要原因是有几个人在项目上工作，其中一个分支需要成为所有创建分支的人的共同基础。
例如，您有要向其添加蓝牙模块的产品，然后在您将其合并到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