git - 获取第一个版本的 Git 工作流程

Question

使用 git，我了解分支以及如何在网站上线后在日常开发中使用 master、develop、feature 分支等。

但是对于为了让网站首次发布构建而发生的最初的大量开发（12 周左右），我不太确定最好的分支策略。

在这个阶段直接提交并推送到master上可以吗？如果不是，那么在第一个版本之前的初始开发阶段，git 的首选策略是什么。

Answer 1

在这个阶段可以直接提交并直接推送到master上吗

理论上，No:master只能包含您的代码的稳定可用版本。
最好是在生产中运行的内容（您网站的实时版本）

正如下面的 charles 评论，这取决于您在克隆 repo 时默认要执行的操作

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

您可以将该集成阶段隔离在其自己的分支上，这是一个或多个特性分支合并的结果，以便一起测试所有特性。

第一个版本将看到：

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

---

现在在实践中（这是我同意查尔斯的回答的地方），如果您正在开发的所有功能都将使其首次发布，您可以开发所有内容master，发布它，放置标签1.0。

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

同样，根据您希望master分支具有的默认角色，您可以直接在其中进行开发。
尽量避免从主分支合并到其他分支（“反向合并”）。
如果您有必须在过去版本中支持移植的功能，请在它们自己的分支中开发它们，然后再将它们合并master到其他版本分支。

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

我们的想法是只承诺master您确定会在下一个版本中使用的功能。

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

Answer 2

您应该分支的唯一时间（我的意思是创建一个单独的中央命名共享分支）是您有一些开发目标，您不希望所有更改通常会进入您提议的原始分支到分支。

听起来您所做的所有工作都在朝着您的一个目标努力——第一次发布。在这个阶段，似乎没有充分的理由拥有多个分支机构。

Answer 3

My recommendation is that you actually do the same practice before and after the main go-live. I think that it is not a good idea to have different practices before and after.

I believe that practice should be to never develop in master, always use branches.

Create a branch and when you've finished with the work for a while and you feel it is in a fairly stable, working state, push it to master.

Branches are very cheap, quick and lightweight, look: checkout -b newbranch I just created one!

Note that this extensive use of branches differs from older version control system where a branch frequently meant you actually wanted to diverage from the main path and go in a different direction.

The one area that I would treat differently perhaps is the 'release' branch which I do agree is a good idea. Before your first release this doesn't exist. After the go-live this will be the branch that is collecting up features/fixes/chores ready for QA and release into master for production.

You may also find https://stackoverflow.com/a/9204499/631619 useful for more git info.

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提到了很多。

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