对于git非专家来说，建议使用多个版本发行版和git-flow [英] Advice on multiple release lines and git-flow, for git non-gurus
问题描述
大量搜索没有提供关于让Git和Git Flow适应我们的需求。出现的情况是，Git Flow不太适合同时支持多个版本。一个有关SO的相关讨论有答案，指出需要使用单独的分支名称来跟踪不同版本的历史记录。除非修改Git Flow，否则这和相关策略会消除Git Flow;看到我们团队的局限性，这是为什么这对我们不实际的原因。
关键问题是其他人发现是实现Driessen分支模型的好方法尽可能接近支持多个版本？
更新：
提取下面的答案（特别是@Rasmus '），通过更多针对性的搜索和一些选项的内部讨论，可以得出我们正在实施的以下解决方案，并将我提供的方法作为一种方法，可能与类似条件下的类似团队有关。
我们不会继续使用Git Flow。相反，我们会将Driessen的模型应用于回购中的每个单独发行版，方法是将每个分支名称与其预期的发行字符串相接，例如：
r1.5 / develop
项目的所有版本都包含在Git存储库中。开始一个新的项目版本包括创建一个由释放字符串开头的一小组新的长期分支（例如 r1.6 / develop ，在我们的例子中为 r1.6 / release ;没有 master ，这意味着单个当前良好的可建立状态）。
$ b
我们在服务器上为每个项目建立一个中央公共存储库，这将成为通过本地回购远程链接共享代码的主要途径。推送到这个存储库意味着代码已准备好被其他人使用。将> RX.Y / develop 合并，然后按下 RX.Y / release 分支表示要发布的代码。 功能，修补程序，等等。人。分支机构被类似地处理给定版本行的分支合并/提交历史记录清晰易懂。我们不希望典型的Git分布式回购策略倾向于避免合并这种回购的复杂性，随着时间的推移，这种回购可能会在结构上发生分歧。
在一些Git GUI（例如SourceTree）这个分支结构被识别并显示为层次结构，这有助于从分支结构中了解项目的顶层历史记录。
对任何答案不投票表示歉意;我在SO上的声誉还不是最低要求。
我们有类似的设置，除了我们有超过300位专业开发人员，我们正是您所描述的我们需要向不同客户提供的几项修订。
我们已经划分了它，所以我们有一个初始参考文献，如refs / heads / platformX.Y /然后我们建立这个文件。
因此，根据你需要做什么结账platformX.Y /开发并开始在某个功能分支上的这一点开始工作，并在完成后合并开发。
这适用于我们，我们可以遵循nvie模式。我们正在将所有这些platformX.Y分支合并到我们的主要开发分支，以便在这些分支上更正的错误也发布到最新的软件中。
Our software product line requires developing and maintaining multiple software versions concurrently. We are relative Git newbies and recently adopted Git Flow to take advantage of Driessen's branching model. We have a very small software team with few dedicated developers (we all wear many hats) and no "integration guru."
Much searching has turned up little specific advice on how to adapt Git and Git Flow to our needs. What has turned up is that Git Flow is not well suited to supporting multiple versions concurrently. One related discussion on SO has answers indicating separate branch names need to be used to track separate versions' histories. This, and related strategies, eliminates Git Flow unless it is modified; see our team limitations above for a reason why this isn't practical for us.
The key question is what have others found to be a good approach for implementing Driessen's branching model as closely as possible while supporting multiple release lines?
UPDATES:
Distilling the answers below (particularly @Rasmus') with more targeted searching and internal discussions on a few options leads to the following solution that we are implementing, and which I offer as one approach that may be relevant to similar teams under similar conditions.
We won't continue to use Git Flow. Instead, we will apply Driessen's model to each individual release line in a repo by prefacing each branch name with its intended release string, e.g.:
r1.5/develop
All versions of a project are contained in the Git repository. Starting a new project version consists of creating a small set of new long-lived branches prefaced by the release string (e.g. r1.6/develop and, in our case, r1.6/release; no master with its implication of the single current good buildable state).
We establish one central public repository per project on a server that will be the main avenue for sharing code through local repo remote links. A push to this repository signifies code that is ready to be consumed by others. Merging RX.Y/develop into and then pushing the RX.Y/release branch signifies code that is intended for release. feature, hotfix, et. al. branches are handled similarly. The branch merge/commit history for a given release line is clean and understandable. We don't want the typical Git distributed repo strategy in favor of avoiding the complexity of merging such repos that, over time, are likely to diverge in structure.
In some Git GUIs (such as SourceTree for example) this branch structure is recognized and displayed as hierarchical, which helps understand the top-level history of a project from the branch structure.
Apologies for not up-voting any answers; my reputation on SO is not yet the minimum required to do so.
we are having a similar setup except we have more than 300 dedicated developers, we have exactly what you described several revision we need to deliver to different customers.
We have divided it so we have an initial ref like refs/heads/platformX.Y/ then we build on that
So depending on what you need to do you checkout platformX.Y/develop and start working from that point on a feature branch and you merge back to develop when you are done.
This works for us and we can follow the nvie model.
on top of everything we are merging all these platformX.Y branch to our main develop branch so errors corrected on those branches are released in to the latest software as well.
这篇关于对于git非专家来说，建议使用多个版本发行版和git-flow的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
