我在我的企业中使用GitLab作为存储库，我正在尝试调查分支管理中的一些标准。我见过this，这是关于Bitbucket分支结构的建议。
我想知道它与主分支和其他分支等更容易的结构相比，它提供了哪些优势。
据我所知，该标准是 origin 服务器中的文件夹结构，您可以在其中找到：master，hotfix，feature，bugfix和release文件夹，其中每个文件夹都有相关的分支。< / p>
这是对的吗？ 您能否向我提供更多信息以便更好地了解它？
答案 0 :(得分：1)
让我向您解释文件夹和分支之间的区别。
文件夹只是一个文件夹，一个目录。它可以在任何分支中。它包含项目文件，子目录等。
另一方面，分支用于允许多个人在同一个项目上工作而不会互相干扰。假设两个人在项目的不同区域工作，但共享一些文件。他们所做的是，他们都打开自己的分支，例如branch_joe和branch_lidi。现在，不是推送到master，而是推送到他自己的分支。通过这样做master（通常用于主项目）完整无缺。在他们完成整个项目的一些子问题的工作后，他们将他们的分支与master合并。应用更改，合并发生，一切都很好。
但为什么他们不能首先推到master？好吧，因为他们正在更改同一个文件foo.c，例如，会出现问题。我们假设Lidi先改变foo.c并推送到master。现在Joe也想推，但他不能，因为他不在分支master上的最新提交。他首先需要拉，但现在分支foo.c上有更新版本的master。如果他没有更改foo.c，他的本地版本将被成功覆盖，因为git会知道他的本地版本来自之前的提交。但是因为他在他的机器上改变foo.c，git感到困惑。不确定是否覆盖Joe的本地文件，而不是复制Lidi提交的文件或做什么。在这种情况下，它会将文件合并到一些临时文件中，其行如此>>>>><<<<，Joe必须手动编辑文件以选择他想要的更改。正如你所看到的，这很烦人且耗时。
但如果他们各自在自己的分支上工作，Lidi会将新的foo.c推送到branch_lidi。既然Joe想推他的foo.c，他会把它推到branch_joe，因为分支不重叠，Lidi的提交不会打扰Joe的foo.c而他会推他的分支出了问题。完成工作后，他们将分支合并到master。合并后，他们也可以删除他们的分支，如果他们不再需要它们。
希望这足够解释，我没有失去你。
答案 1 :(得分：1)
我一直在谷歌上搜索更多，我发现this post。
非常容易理解如何使用git和分支名称约定正常工作。
希望帮助别人。