获得首次发布的Git工作流程

Question

使用git，我了解分支以及如何在网站开发后的一天中使用master，develop，feature branches等进行开发。

但是为了让网站首次发布版本，最初发生的大部分开发（大约12周左右）我不太确定最佳分支策略。

在这个阶段提交和直接推送主人是没关系的吗？如果没有，在第一次发布之前的初始开发阶段，git的首选策略是什么。

Answer 1

  

在此阶段提交和直接推送主

是否正常

理论上，No：master只能包含代码的稳定可用版本 优选生产中运行的内容（网站的实时版本）

正如下面的查尔斯评论，这取决于您在克隆回购时默认情况下要执行的操作

  

在第一次发布之前的初始开发阶段，git的首选策略是什么。

您可以在自己的分支上隔离集成阶段，这是合并一个或多个 feature branch 的结果，以便测试所有功能齐全。

第一个版本将会看到：

• 合并到master
• 标记1.0
• 从所述标记完成的分支1.0_hotfix，以隔离以下热修复：
  • 您将合并到master
  • 如果您认为修补程序在新的上下文中有意义，那么您将合并到当前为2.0开发的其他功能分支（由于某些2.0重构，某些错误在2.0中实际上并不相关）

---

现在正在实践中（这是我同意Charles的answer），如果所有您正在开发的功能将首次发布，那么可以开发master上的所有内容，发布它，添加标记1.0。

但是一旦完成第一个版本，我仍然会建议在他们自己的分支中隔离热修复。

同样，根据您希望master分支拥有的默认角色，您可以直接在其中进行开发 尽量避免从主服务器合并到其他分支（“back merge”） 如果你有功能，你必须在过去的版本中支持端口，在将它们合并到master和其他版本分支之前，在它们自己的分支中开发它们。

作为遵循该模型的大型项目示例（master上的开发和发布的分支），您可以看到 gitlabhq 的组织。

我们的想法是只提交master功能，确保确保将进入下一个版本。

实验性功能（可能会或可能不会实现）应该在他们自己的分支中隔离（或者在克隆回购中的master，但，并通过拉取请求合并。）

Answer 2

你应该分支的唯一一次（我的意思是创建一个单独的中心命名共享分支）是你有一些开发目标，你不希望通常会发生的所有变化进入你提议分支的原始分支。

听起来你正在做的所有工作都是为了实现你的目标 - 首先发布。在这个阶段，似乎没有充分理由拥有多个分支。

Answer 3

我的建议是你在主要上线之前和之后实际做同样的练习。我认为在之前和之后进行不同的练习并不是一个好主意。

我认为练习应该永远不要在大师身上发展，总是使用分支。

创建一个分支，当你完成工作一段时间后，你觉得它处于一个相当稳定的工作状态，把它推到掌握。

分支机构非常便宜，快速而轻巧，外观：checkout -b newbranch我刚创建了一个！

请注意，分支的广泛使用与旧版本控制系统的不同之处在于，旧分支通常意味着您实际上想要从主路径中分流并朝着不同的方向前进。

我会区别对待的一个领域可能是“释放”分支，我同意这是一个好主意。在第一次发布之前，这不存在。在上线之后，这将是收集功能/修复/家务准备QA并发布到master进行生产的分支。

您可能还会发现https://stackoverflow.com/a/9204499/631619对更多git信息非常有用。

Answer 4

我最喜欢的最佳做法是git-flow提供的建议

http://nvie.com/posts/a-successful-git-branching-model/

和相应的工具

https://github.com/nvie/gitflow

我总是解释这个，你应该在develop分支上进行初始开发。在开发分支中，您可以使用分支，当您即将发布时，您可以执行发布分支。实际执行生产版本时，只将发布分支合并到master。

Answer 5

通常，当我们谈论git工作流时，我们假设我们在stable stage。通过这种方式，我的意思是我们已经进入了几个星期的开发阶段，添加新内容或进行更改通常是日常生活。

但我认为工作流实际上随着代码的年龄而发展。

例如，当您第一次创建项目时，您不必费心去创建分支。当你甚至没有开始编码时，考虑git是没有意义的。这是一个实验阶段。你写的一切都可能是垃圾。

经过几天的开发，您的项目开始成型，您不想破坏它的稳定部分。而且您还希望与您的团队成员合作。因此，您需要为新功能创建branches。但是，由于整体代码库仍然很小，merge，所以很快就会master manageable git workflows。

一旦代码太大而无法管理，那么您实际上是在谈论workflows来管理它。整个地方都提到了很多{{1}}。

因此，要回答您的问题，如果您的代码库很小，请专注于立即制作产品，而不是管理代码。