首次发布的Git工作流程 [英] Git workflow for getting to first release

问题描述

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

Using git, I understand branching and how to use master, develop, feature branches etc. in day to development for a website after it has gone live.

但是对于最初要进行的大部分开发工作(约12周)，以便使网站首次发布，我不确定最佳的分支策略.

But for the initial big chunk of development that takes place (12 weeks or so) in order to get the sites first release build I'm not so sure of the best branching strategy.

在此阶段直接提交并推送给master可以吗?如果不是，那么在第一个发行版之前的初始开发阶段，git的首选策略是什么.

Is it fine in this stage to commit and push directly on master? If not, what is the preferred strategy for git during the initial development phase before the first release.

推荐答案

在此阶段直接提交并推送到master上就可以了

Is it fine in this stage to commit and push directly on master

从理论上讲，否: master 只能包含稳定的可用版本的代码.
最好是在生产环境中运行(您网站的实时版本)

In theory, No: master could only contain stable usable version of your code.
Preferably what is running in production (the live version of your website)

如下面的查尔斯评论所述，这取决于克隆存储库时默认情况下要执行的操作

As charles comments below, it depends what you want to do by default when cloning a repo

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

what is the preferred strategy for git during the initial development phase before the first release.

您可以在自己的分支上隔离该集成阶段，这是一个或多个

You can isolate that integration phase on its own branch, which is the result of the merge of one or several feature branch, in order to test all features together.

第一个版本将显示:

• 合并到 master
• 标签 1.0
• 从所述标记完成的分支 1.0_hotfix ，以便隔离具有以下功能的热修复程序:
  • 您将合并到 master
  • 如果您认为此修补程序在新的上下文中有意义，那么您将合并到当前为 2.0 开发的其他功能分支(由于2.0重构，某些错误实际上与2.0不相关)li>
  • a merge to master
  • a tag 1.0
  • a branch 1.0_hotfix done from said tag, in order to isolate hot fixes that:
    • you will merge to master
    • you will merge to other feature branches currently developed for 2.0 if you think that hotfix makes sense in that new context (some bugs aren't actually relevant in 2.0 because of some 2.0 refactoring)

    现在开始练习(这就是我同意 Charles 的

    Now in practice (and this is where I agree with Charles's answer), if all the features you are developing will make it to first release, you could develop everything on master, release it, put a tag 1.0.

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

    But once the first release is done, I would still recommend isolate hot fixes in their own branch.

    同样，根据您希望 master 分支具有的默认角色，可以直接在其中进行开发.
    仅尝试避免从master合并到其他分支("反向合并").
    如果您有功能，则必须在以前的发行版中进行移植，在将它们合并到 master 和其他发行版分支之前，请先在各自的分支中进行开发.

    Again, depending on the default role you want master branch to have, you can develop directly in it.
    Try only to avoid merging from master to other branch ("back merge").
    If you have feature you have to back port in past release, develop them in their own branch before merging them to master and to other release branches.

    作为遵循该模型的大型项目的示例(在 master 上开发，并发布分支)，您可以看到

    As an example of a large project following that model (development on master, and branches for release), you can see the organization of gitlabhq.

    这个想法是只承诺您确定 会将其用于下一个版本的 master 功能.

    The idea is to only commit to master feature that you are sure will make it to the next release.

    实验功能(可能会或可能不会成功)应该隔离在自己的分支中(或在 master ， but 在 中隔离)>回购，并通过拉取请求合并).

    Experimental features (that might or might not make it) should be isolated in their own branch (or in master, but in a cloned repo, and merged through pull requests).

    这篇关于首次发布的Git工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！