不同版本框架的 Git 工作流程

发布于 2024-12-29 11:42:21 字数 1104 浏览 1 评论 0原文

我们有以下设置:三个彼此相似的应用程序,将公共代码提取到框架中。每个应用程序都在自己的 git 存储库中进行管理,并将框架作为 git 子模块包含在内。

问题在于,应用程序现在是与添加到框架中的新功能并行开发的,而其他应用程序不需要立即支持。目前,我们为所有应用程序提供了不同的框架分支。一个应用程序使用框架的主分支,因为大多数时候新功能都是在此应用程序中首次引入的。

框架分支

  • master(由应用程序 A 使用)
  • appB
  • appC

当 appB 中引入需要在框架中进行更改的新功能时,会对分支 appB 进行这些更改。如果应用程序 A 稍后需要这些更改,则分支应用程序 B 会合并到主分支中。这意味着 appB 中的所有更改都必须合并到 master 中。

这个系统可以工作,但有一些缺陷,

  • 将一个功能从一个分支合并到另一个分支意味着我们必须合并所有更改,
  • 很容易在将一个分支合并到另一个分支时丢失跟踪已经合并的内容或将要合并的内容
  • 标记重大更改已完成使用提交消息,这使得最后一点变得更加重要

我们目前正在寻找新的工作流程。我正在考虑让以下分支

  • master
  • appA
  • appB
  • appC

因此,对于每个应用程序,一个分支和一个包含所有更改的 master 分支。当开发新功能时,应该创建一个功能分支,然后将其应用到主分支以及所有应用程序分支,立即需要该功能。其他应用程序可以在以后需要该功能时合并该功能分支。

我看到以下问题:

  • 如何将功能分支合并到多个分支上,并且仅合并分支中发生的更改。我知道“git rebase into ...”,但我不太确定是否可以多次使用此命令。
  • 我应该使用 gitcherry-pick 将功能合并到多个分支中吗?我宁愿不这样做,因为我认为如果不选择功能分支中所做的所有更改
  • 如何跟踪哪个功能(分支)已应用于哪个应用程序,这将很容易出错。我可以使用branch --no-merge 还是只有当分支具有相同的祖先时才有效?

我的目的是实现这一目标的最佳方式还是我应该完全重新考虑我的策略?

We have the following setup: Three apps which are similar to each other with the common code extracted into a framework. Each app is managed in their own git repository and includes the framework as a git submodule.

The problem is that the apps are now developed in parallel with new features being added to the framework that other apps don't need to support right away. Currently we have different branches of the framework for all apps. One app uses the master branch of the framework because most of the time new features were first introduced in this app.

Framework branches

  • master (used by App A)
  • appB
  • appC

When a new feature is introduced in appB that needed changes in the framework these changes were made to branch appB. If these changes were later needed in App A, branch appB was merged into master. This means that all changes in appB had to be merged into master.

This system worked but had some flaws

  • merging a feature from one branch to another meant we had to merge all the changes
  • easy to loose track what had been merged already or what is going to be merged when merging one branch into another
  • Marking breaking changes was done using commit messages, which made the last point even more important

We are currently searching for a new workflow. I was think about having the following branches

  • master
  • appA
  • appB
  • appC

So for each app one branch and a master branch that includes all the changes. When new features are developed a feature branch should be created and then applied to master as well as to all app branches the feature is needed right away. Other apps can merge the feature branch when they need the feature later on.

I see the following problems with this

  • How can I merge a feature branch onto multiple branches and only merge the changes that happened in the branch. I know of "git rebase onto ..." but I am not quite sure if I can use this command multiple times.
  • Should I use git cherry-pick for merging features into multiple branches? I would rather not do this, because I can think that this will be error prone when not selecting all changes that were made in a feature branch
  • How to keep track of which feature(branch) had been applied to which app. Can I use branch --no-merge or will that only work if the branches have the same ancestor?

Is my purposed way the best way to accomplish this or should I rethink my strategy completely?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我也只是我 2025-01-05 11:42:21

正如“Git 和在多个分支上工作”中所解释的,这两种实用的解决方案将提交应用于多个分支(这就是您使用“功能分支”选项所做的事情)是:

  • 合并(这应该允许您继续重用该功能分支,因为它将跟踪已经合并到特定分支的内容):一个rebase --interactive 可能是为了让您重新排序提交,首先放置您想要合并的提交,然后放置您尚未准备好合并的提交。
  • 樱桃采摘(而且它现在支持一系列提交),但我总是对挑选樱桃持谨慎态度

As explain in "Git & Working on multiple branches", the two practical solutions when applying commits to multiple branches (which is what you would do with your "feature branches" option) are:

  • merge (which should allow you to keep reusing that feature branch, as it would keep track of what has already been merge to a specific banch): a rebase --interactive might be in order for you to re-order the commits, putting first the ones you want to merge, and then the ones you are nnot ready yet to merge.
  • cherry-picking (and it now supports a range of commits), but I always have been wary of cherry-picking.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文