Git 嫁接有危险吗?

发布于 09-25 12:04 字数 1294 浏览 7 评论 0原文

我一直使用 Git 作为 Subversion 存储库的胖客户端,这非常棒。我应该遵循每个 Trac 票证一次提交的方法,但为了我自己的利益,我更喜欢拥有丰富的原子提交历史,因此我养成了以下习惯:

  1. 为 Trac 票证创建主题分支
  2. 破解,进行多次提交
  3. 在断开连接的 HEAD 上使用 git rebase -i 将所有工作捆绑到单个提交中(保持主题分支完整)
  4. 使用 git svn dcommit 来提交到 SVN
  5. 将功能合并回 master,然后从 trunk 合并到 master (第二步通常是无操作,因为 trunk并且功能分支应该匹配)

这使 mastertrunk 保持良好同步,同时保留我想要的所有历史记录。唯一的问题是,Git 认为 master 永远领先于 trunk,因为据它所知,我从未真正提交过主题分支或 master 回到 trunk — 步骤 #3 丢失了更改的祖先,因此 Git 看到的只是 trunk 自身和 master 嗡嗡作响code> 合并它和主题分支:

Switched to branch 'master'
Your branch and 'trunk' have diverged,
and have 232 and 1 different commit(s) each, respectively.

现在,我实际上知道这是一个问题。我基本上是唯一一个在这个 SVN 存储库中工作的人,因此并不存在需要处理的棘手合并,这可能会造成混淆。但原则上这让我很困扰(我就是这样)。我希望 trunk 提交能够反映它们的“真实”血统 - 每个提交都是与之前的 SVN 修订版本(作为父版本)和主题分支(作为另一个版本)的合并。

你瞧,有 .git/info/grafts,它似乎正是我想要的。我什至可以将 trunk 合并到 master 作为快进合并,从道德上讲,它通常绝对是这样。但尽管结果可能很漂亮,但它似乎很糟糕,特别是因为它可能不是绝对必要的。

所以我想知道的是,这个想法有什么危险吗?比如说,如果我养成了每次进行rebase/dcommit舞蹈时进行移植的习惯,我是在自找麻烦吗?我应该克服自己吗? :-)

I've been using Git as a fat client for a Subversion repo, which has been great. I'm supposed to follow the one-commit-per-Trac-ticket methodology, but I much prefer having a rich history of atomic commits for my own benefit, so I've gotten into the following habit:

  1. Make topic branch for Trac ticket
  2. Hack away, making several commits
  3. Use git rebase -i on a disconnected HEAD to bundle all the work into a single commit (keeping the topic branch intact)
  4. Use git svn dcommit to commit to SVN
  5. Merge the feature back to master, then merge from trunk to master (this second step is generally a no-op, since trunk and the feature branch should match)

This keeps master and trunk nicely in sync while keeping all the history I want. Only trouble is that Git thinks that master is forever well ahead of trunk, since as far as it knows I've never once actually committed either a topic branch or master back to trunk — step #3 loses the ancestry of the changes, so all Git sees is trunk humming along by itself and master merging both from it and the topic branches:

Switched to branch 'master'
Your branch and 'trunk' have diverged,
and have 232 and 1 different commit(s) each, respectively.

Now, I don't actually know that this is a problem. I'm mostly the only one working in this SVN repo, so it's not like there are tricky merges to deal with that could get confused. But it bothers me, just on principle (I'm like that). I'd like the trunk commits to reflect their “true” ancestry — each one is a merge with the previous SVN revision as one parent and the topic branch as the other.

And lo and behold, there's .git/info/grafts, which appears to do precisely what I want. I can even merge trunk to master as a fast-forward merge, which morally it usually absolutely is. But pretty though the results may be, it seems kludgy, especially since it may not be absolutely necessary.

So what I want to know is, is there anything dangerous about this idea? If I, say, get into the habit of making a graft each time I do the rebase/dcommit dance, am I asking for trouble? Should I just get over myself? :-)

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

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

发布评论

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

评论(2

一百个冬季2024-10-02 12:04:54

老问题,我知道,但是:

我认为保持“主干”和“主人”之间的区别会让你的生活变得不必要的困难。 “master”通常应该指向 svn 树的顶部,或者指向您要提交的快速修复。但是,当您捆绑了一系列更改并提交时,我认为下一个合乎逻辑的步骤是设置移植,以便您提交的更改既是其 svn 父级又是您以前使用的主题分支的子级写下门票的代码。换句话说,从 git 的角度来看,您提交的更改变成了 svn 树和您的主题分支的合并——从很多方面来说,这就是它的本质。根本不需要创建主题分支的真正 git 合并。

Old question, I know, but:

I think maintaining a difference between "trunk" and "master" is making your life harder than necessary. "master" should generally point to the top of the svn tree, or to quick fixes you're about to dcommit. When you've bundled up a series of changes and dcommitted, them, though, I think the next logical step is to set up a graft so that the change you dcommitted is a child of both its svn parent and the topic branch you used to write the code for the ticket. In other words, the change you dcommitted becomes, from git's perspective, a merge of the svn tree and your topic branch -- which, it many respects, is what it is. There's no need to create a bona fide git merge of the topic branch at all.

-柠檬树下少年和吉他2024-10-02 12:04:54

我建议你放弃 svn,因为你是唯一使用它的人并坚持使用 git,但假设你出于某种原因不能这样做,那么我建议你停止与你的工具作斗争,只在平常使用 git-svn感觉。

考虑放弃本地历史记录,转而使用发送到 svn 的“经过修饰的”历史记录。您的本地历史反映了您自己的工作,这是您尚未准备好向世界展示的工作 - 某些测试用例可能会失败,或者代码风格可能很难看,等等。进行本地提交,完善它,测试它,然后将其放入一个漂亮的小提交中以上传到 svn 服务器。

无论如何,您仍然可以暂时使用引用日志进行本地更改。如果您确实想保留自己的本地 hack,请考虑标记它们或其他东西,这样它们就不会弄乱您的主分支。

I suggest you ditch svn, since you're the only one using it and insist on using git, but supposing you can't do that for whatever reason, then I suggest you stop fighting your tools and just use git-svn in the usual sense.

Consider dropping your local history in favour of the "polished" history you're sending to svn. Your local history reflects your own work, which is work you're not yet prepared to show the world - certain test cases may be failing, or the code style may be ugly, etc. Make a local commit, polish it up, test it, and THEN put it into a nice little commit to be uploaded to the svn server.

You'll still have your local changes anyway using the reflog, for a time. If you really want to keep your own local hacks, then consider tagging them or something, so that they don't clutter your master branch.

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