我们在小组中讨论了针对每个功能打开新分支的做法。
有些声音认为这有点多余。 他们建议我们可以在同一个分支上工作，并在需要时对它进行更改。 他们说，无论如何，我们在尝试推动时将面临合并问题。
我认为我们应该为每个功能打开一个功能分支。 你觉得呢？
（如果不是这个问题的地方，请告诉我它适合的地方）
谢谢！
答案 0 :(得分：4)
每当您问任何形式的问题：“是A与B的区别”时，最好对A和B的确切定义都有一些精确的定义。
不幸的是，在Git中 branch 的定义（故意）是模糊的。我敢打赌，您和您的同事都有不同的个人定义。他们也可能全错了。 seriously更严重的是，他们可能在某些事物上达成共识，而在其他事物上达成共识，并且有多个合理的定义。另请参见What exactly do we mean by "branch"?
Git是分布式的，因此每个人都将拥有自己的某些Git存储库的克隆。可能存在或可能不存在某些特殊的Git存储库-通常是存储在GitHub上的存储库，每个人都同意将其视为一种“主要”，“主”或“主导”或您所使用的任何词最好使用集中式的真实源版本库，以便将其他所有人的实际对等存储库视为某种程度较小的实体。但是Git的设计是分散的，每个存储库都非常自治。
因此，每个存储库都有其自己的独立分支名称。即使您在您的 Git dev中调用您的分支，而Bob也会在 his 中调用 his 分支Git dev，然后Carol在她的 Git dev中称呼她的分支，依此类推，这些实际上都是独立的分支名称。所有这些都可以很好地隔离。您将遇到的问题是，当Bob尝试与Carol交谈时，他会说“用dev ...”，而Carol会认为Bob的意思是她 dev鲍勃实际上是指他的 dev。如果Bob和Carol试图让他们的两个Git互相保持Git-repo-sex 1 ，这会变得更糟，因为如果没有仔细的指导，他们的Git将会尝试使他们的两个{{1 }}。
的意思是给每个人自己的自己分支名称很有帮助。 2 Bob的Git是否直接与Carol的对话，或者Bob和Carol是否都让他们的Git在GitHub上调用Git以便进行Git-repo-mating-dance。对我们头脑模糊的人来说，谈论“分支dev中的最后两个提交”要比说“提交xyz和提交b697d92f56511e804b8ba20ccbe7bdc85dc66810”容易得多。后者是精确的，并且在所有情况下都可以使用-这两个提交始终都是 这两个提交-但哈希ID只是不适合人类使用。
1 对不起，很热。 ?您可以使用6ee1eaca3e996e69691f515742129645f453e0e8或git fetch将两个Git连接在一起。请注意，git push运行git pull，然后运行第二个Git命令，因此它实际上也只是使用git fetch来交换提交。
2 请注意，我在这里一直在谈论分支名称。这种区别很有用：如果我们将 branch 定义为一系列提交，这些提交以分支名标识的提示提交结束，那么到某个时候，每个开发人员都会拥有一个或多个他或她自己的分支-每次有人使用分支名称进行新提交时，他或她都会进行新的唯一提交，这将更新该分支名称，从而创建新分支。因此，无论有没有唯一的分支名称，这些开发人员都将拥有唯一的分支。
答案 1 :(得分：1)
因此，您是说每个人都在他们的远程副本上工作，并且在功能完成而不是分支之前不会推送吗？
如果您永远不希望共享或了解功能分支，直到它们准备好合并到master分支中，这基本上是相同的。我认为这不是一个好主意。
创建分支使您可以选择将进度显示给组中的其他成员，并让他们有机会了解您所更改的内容，甚至可以将功能分支合并到自己的分支中实际上将您的分支合并到master分支中。因此，这也可以减少合并冲突。
创建分支！这是有用的做法。
答案 2 :(得分：1)
按照优良作法，我们应该使master分支与生产代码保持同步。如果有任何发行版，请从master创建发行分支并提供给开发人员。 从开发人员的角度来看，他们必须从发布分支创建自己的功能分支或jira分支，进行自己的更改并返回到github。 在对发布分支提出提升请求之后，我们已经在发布分支中合并了。