英文:

git branching strategy for .NET major versions and release branches

问题 {#heading}

对于包含多个类库的.NET项目，我目前正在使用以下的Git分支策略：

                   feature 1
                 +------------+
               ^/              \
      master   /                v
    ----------+-+---+---------- PR ----+------+-----------
                 \   \                  \      \
                  \   v  release/7.0     \      v
                   \  +------------------ \ ----+--------- 我从主分支分支出来，并将"版本"设置为7.0.0、7.0.1等。aspnetcore包的版本也指向7.x.x
                    \                      \
                     v  release/6.0         v
                     +----------------------+------------- 我从主分支分支出来，并将"版本"设置为6.0.0、6.0.1等。aspnetcore包的版本也指向6.x.x

然而，这样做会阻止我正确更新主分支上的.NET版本，因为这些更改也需要合并到发布分支中。所以主分支总是不会更新。

我已经了解了GitFlow，但对于如何解决主分支中的版本更改合并到所有发布分支的问题还不清楚。

如果我使用SourceTree检查asp.net core的分支图，我会发现main分支实际上从未合并到release/6.0和release/7.0分支，但提交仍然会出现在这些分支上：

main分支的版本已更改为8，但这些更改不会传播到其他发布分支。

我以前已经阅读过一些资源，但没有得到答案。
那么，我应该如何正确组织我的Git仓库以正确进行版本控制？

编辑 {#heading-1}

似乎对于angular来说，主分支上的提交可以在发布分支中结束，而不需要手动合并它们。但我想知道他们是如何做到的。提交时间戳相差2秒，所以我认为他们不是手动挑选的。

问题：

• 所以何时/从何处开始的发布过程将0.0.0-PLACEHOLDER替换为实际版本，它是从哪里获取的？还有，他们如何在这个阶段映射相应的依赖版本？
• Angular/asp.net core等是否使用git-flow？或者他们是如何管理多个主要版本并存的？
• 版本号是从哪里来的？

在我看来，我可能需要更改主分支上的版本（以及依赖项的版本），并标记提交以在合并到发布分支时跳过...但这是否可行？

编辑2 {#2}

LinkedIn在他们的开发博客上发布了一篇文章，指向了一个应用程序，用于自动化挑选提交并创建拉取请求。但似乎还有几个GitHub操作。

甚至Google也创建了一个GitHub机器人来创建拉取请求以将提交挑选到发布分支中。 英文:

For my .NET project containing several class libraries, I am currently using the following git branching strategy:

                feature 1
             +------------+
           ^/              \
  master   /                v
----------+-+---+---------- PR ----+------+-----------
             \   \                  \      \
              \   v  release/7.0     \      v
               \  +------------------ \ ----+--------- I branched from master and set the "version" to 7.0.0, 7.0.1, ... The aspnetcore package versions also point to 7.x.x
                \                      \
                 v  release/6.0         v
                 +----------------------+------------- I branched from master and set the "version" to 6.0.0, 6.0.1, ... The aspnetcore package versions also point to 6.x.x

However, doing it like this prevents me from properly updating .NET versions on the master branch, since these changes would also need to be merged into the release branches. So the master branch would always be out-of-date.

I've read about GitFlow, but it's unclear to me how this solves the problem of version changes in the master branch being merged to all release branches.

If I use SourceTree to check the branch graph for asp.net core, I see that the main branch is never actually merged into the release/6.0 and release/7.0 branches, but commits still end up on these branches:

The version was changed in the main branch to 8, but these changes don't propagate to the other release branches.

I've already read several resources in the past, but couldn't get an answer.
So how do I properly organize my git repository in order to do versioning the right way?

EDIT {#edit}

It seems that for angular, commits on the main branch manage to end up in the release branches, without actually merging them. But I'm wondering how they do this. The commit timestamp is 2 seconds apart, so I don't think they cherry-pick it manually

QUESTIONS:

• So when/where does the release process replace 0.0.0-PLACEHOLDER with the actual version, and where does that come from? Also, how do they map the corresponding dependency versions in that stage?
• Are angular/asp.net core/... using git-flow? Or how do they manage multiple major versions next to one another?
• Where is the version number coming from?

It seems to me that I'll have to change the version (+ the versions of the dependencies) on the master, and mark the commit to be skipped when merging into release branches... But is that feasible to do?

EDIT 2 {#edit-2}

LinkedIn posted an article on their dev blog about this, which points to an app to automate cherry-picking and creates pull requests. But there seem to be several github actions too.

Even google created a github bot to create pull requests to cherry-pick commits into release branches

答案1 {#1}

得分: 3

有许多不同的分支管理策略。根据您的需求，有几种处理方式。

樱桃拣选（Cherry-picking）：每当一个功能/错误修复合并到主分支（master），并且需要将其回溯到现有的发布分支时，显式地樱桃拣选相关更改回到相应的分支。在这个模型中，发布分支和主分支从不相互合并。这可以完全控制每个分支中的更改内容。一个风险是您可能会忘记将更改拣选到所有相关的发布分支 - 您可能记得将其拣选到release/6.0，但忘记了release/7.0。

在受影响的最旧发布分支上进行更改，并向前合并：每当需要在发布分支上进行错误修复/功能开发时，首先将更改合并到最旧的相关发布分支。然后将该发布分支合并到下一个发布分支（即将release/6.0合并到release/7.0）。最后将最新的发布分支合并到主分支。这避免了樱桃拣选，所以可能更简单。此外，可以轻松检查所有所需的更改是否已经到达每个发布分支 - 每个发布分支应该在下一个发布分支之前没有提交。它的缺点是您必须提前决定要合并到哪个最旧的发布分支。如果稍后决定要将更改合并到较旧的发布分支，您将需要将原始更改拣选到较旧的发布分支，然后从该发布分支通过已经包含该更改的较新发布分支进行合并（因此合并提交是空的），纯粹是为了回到所有发布分支在下一个发布分支之前都没有提交的状态。值得注意的是，在这个模型中，所有版本号的更改都发生在主分支上，因此在获取发布分支后立即递增主分支上的版本号。

Gitflow分支模型同时具有主分支和开发分支，因此需要管理比您目前管理的更多的分支，因此可能对您的需求过于复杂。

我建议的这两种模型都允许您在主分支上进行任意更改，因为您从不将主分支合并到任何发布分支中。

祝您选择适合您的分支管理策略好运。 英文:

There are many, many ways of managing branching strategies. I think for your purposes there are a couple of ways you could handle things.

Cherry-picking: Whenever a feature/bugfix goes to master and should be backported to existing releases, explicitly cherry-pick the changes back to the relevant branch. In this model the release branches and master branch are never merged into each other. This gives full control over what changes end up in each branch. One risk is that you forget to cherry-pick the change into all relevant releases - you might remember to cherry-pick it to release/6.0 but forget about release/7.0.

Making changes on the oldest affected release, and merging forward: Whenever a bugfix/feature is needed on a release branch, first merge the change to the oldest relevant release branch. Then merge that release branch to the next release branch (i.e. merge release/6.0 into release/7.0). Finally merge the most recent release branch into master. This avoids cherry-picking, so may be simpler. Also, it is easy to check that all desired changes have made it to each release - each release should be 0 commits ahead of the next release. It has the downside that you must decide which is the oldest release you are merging to ahead of time. If you later decide you want to merge the change to an older release, you end up cherry-picking the original change to the older release, then merging from that release through the newer releases which already have that change (so the merge commits are empty) purely to get back to having all releases 0 commits ahead of the next release. Worth noting is that in this model all version number changes occur on master, so you would increment the version on master immediately after taking a release branch.

Gitflow branching model has both master and develop, so requires managing more branches than you currently do, so is probably overcomplicated for your needs.

Both models I have suggested allow you to make arbitrary changes on master, since you never merge master into any release branch.

Good luck with choosing a branching strategy that works for you.