Git Rebase 或 SVN Reintegrate 用于功能分支?

发布于 2024-12-07 17:09:12 字数 388 浏览 0 评论 0原文

我们目前正在使用 SVN,但考虑转向 Git 来支持我们的新工作流程,该工作流程严重依赖于 rebase。

我们正在考虑一种开发工作流程,其中每个单独的功能都在单独的分支上开发,然后在准备发布时合并到 trunk/master 中。分支在合并回 trunk/master 后将始终被删除。

一个建议是使用 git rebase 来使功能分支与 master 中的更改保持同步(这样我们就可以在分支中准确测试将要发布的内容),并简化从分支的合并 -> 。掌握。

我们正在考虑的替代方案是使用 svn merge 使功能分支与主干中的更改保持同步,然后使用 svn merge --reintegrate 将功能分支合并回主干以进行发布。

这些方法有哪些差异和潜在陷阱?哪个更适合我们的工作流程?

We are currently using SVN, but considering moving to Git to support our new workflow, which relies heavily on rebase.

We're considering a development workflow where each individual feature is developed on a separate branch, then merged into trunk/master when it's ready for release. The branch will always be deleted after it is merged back into trunk/master.

One proposal is to use git rebase to keep the feature branch up-to date with changes in master (so we can test in the branch exactly what will be released), and to simplify the merge from branch -> master.

The alternative we're considering is to use svn merge to keep the feature branch up-to-date with changes in trunk, then using svn merge --reintegrate to merge the feature branch back into trunk for release.

What are the differences and potential pitfalls of each of these approaches? And which is more appropriate for our workflow?

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

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

发布评论

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

评论(1

江南月 2024-12-14 17:09:12

这是 git 中非常简单的工作流程。一些开发人员使用您所描述的一种或两种方法。

就我个人而言,我是 scott Chacon 的策略的粉丝,并且已经找到了它真的很有用。

你可以通过变基来保持 master 分支处于线性历史中,这很正常,但它确实有可能会给刚开始使用 git 的人带来一些主要循环。变基会更改历史记录,如果不小心的话,确实可能会导致问题。

如果您刚刚开始,Git-merge(不是您提到的 svn-merge --reintegrate)在 git 中更简单一些。 Git 的合并策略确实经过深思熟虑,可以自动让您摆脱麻烦。

如果我在功能分支上进行开发,然后将其合并到 master 中,我喜欢在 master 上运行 git merge --no-ff feature 来创建合并提交,只是为了明确。

由于您刚刚开始使用 git,因此我会选择合并工作流程。恕我直言,如果您来自 svn 背景,这会更直观。

This is a really straightforward workflow in git. Several developers use one or both of the methods you described.

Personally, I'm a fan of scott Chacon's strategy and have found it really useful.

You can rebase to keep the master branch in a linear history, and that's normal, but it does have a slight possibility of throwing some major loops to guys just starting out in git. Rebasing changes history and can really cause problems if you're not careful.

Git-merge (not the svn-merge --reintegrate you noted) is a little more straightforward in git if you're just starting out. Git's merging strategies are really well thought out and automatically keep you out of trouble.

If I'm developing on feature branch and then merging it into master, I like to run git merge --no-ff feature while on master to create the merge commit just to be explicit.

As you're just starting out with git, I'd go for the merge workflow. IMHO, it's more intuitive if you're coming from a svn background.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文