相关链接

返回首页

Hibernate迁移到Git + Git技巧和窍门

由 发布    |       讨论 Hibernate Validator

你可能还不知道，但Hibernate Core和Hibernate Validator的源代码现在已在Git上，Hibernate Search和其他项目可能很快也会跟随。迁移的原因有很多，但简而言之，在SVN下生活并不坏，但在Git下真的非常好。

获取Hibernate源代码

公共“参考”Git仓库托管在GitHub。我们并非只依赖GitHub，但到目前为止，我们真的很喜欢他们提供的基础设施。向他们致敬！无论如何，迁移只需一个克隆即可完成。这往往会让这类服务保持警惕。

Hibernate Core在这里，而Hibernate Validator在那里。

贡献

如果你想要贡献一个修复或新功能，可以

  • 使用GitHub分叉功能：克隆、在一个分支上工作、在GitHub上分叉仓库（分叉按钮）、将工作推送到那里并触发拉取请求（拉取请求按钮）。还可以参阅http://help.github.com/forking和http://help.github.com/pull-requests
  • 使用纯Git方法：克隆、在一个分支上工作、将工作推送到托管在某处的公共分叉仓库，触发拉取请求git pull-request
  • 提供一个传统的补丁文件：克隆仓库、使用git format-patch或diff创建补丁文件，并将其附加到JIRA

我们更喜欢GitHub、纯Git和补丁

  • GitHub让我们可以以细粒度方式对你的更改进行评论
  • Git通常会导致更多的小提交，更容易跟踪
  • 一个100k的大补丁总是令人沮丧，而且难以更新

如果你仍然想用旧的方式提供一个补丁文件，那也可以。

关于Git的各种提示

虽然并非全面，但这里收集了一些在使用Git时有用的提示。

阅读相关书籍

时间将证明这是值得的。我特别喜欢Pro Git这本书。它是一本很棒的书，非常实用。它有免费的html和epub版本（建议购买树形版本以回报作者）。

克隆

我更喜欢git协议来克隆，而不是http（专家们这么说）。至少这将快得多。从GitHub克隆仓库只花了我不到3分钟。

#for people with read/write access
git clone git@github.com:hibernate/hibernate-core.git

#for people with read-only access
git clone git://github.com/hibernate/hibernate-core.git

这将创建一个名为origin的远程链接。我通常倾向于将其重命名，以反映其实际内容。

git remote rename origin core-on-github

请注意，您可以将多个远程仓库附加到本地仓库

git clone git://github.com/hibernate/hibernate-core.git
git remote rename origin ref-core-github
git remote add manu-core-github git@github.com:emmanuelbernard/hibernate-core.git
git fetch manu-core-github

推送和拉取

要最初在本地获取远程分支的副本，请执行

git checkout -b 3.6 origin/3.6

在拉取分支时，最好在原始仓库和您的克隆之间保持相同的名称。在这种情况下，许多语法都有快捷方式（Hardy，你在听吗？ ;)）。然后您可以执行

git push origin master

如果您将分支master重命名为local-master本地，请执行

git push origin local-master:master

要删除远程仓库上的分支，请推送一个空分支

git push origin :branch-to-remove

分支

始终在一个主题分支上工作，并在完成后合并您的作品。

git checkout master
git checkout -b HHH-XXX
#hack commit hack commit

不要忘记在提出请求拉取之前从您的master分支拉取并重新base此主题分支。

这样做有许多优点，其中之一是您可以在并行工作，并轻松与参考master同步。

同样，如果您想与Hibernate团队的人共享工作，请将其推送到公共仓库，并定义主题分支的拉取请求。确保您的主题分支位于最新master之上。

提交

更喜欢小提交，它们将更易于阅读，并且不太可能在合并时失败。

编写好的注释（一行包括涉及的问题编号和摘要，然后是一行空白，如果需要，再附上更详细的解释。

HHH-XXX Fix NPE on persist

Fix stupid bug by Gavin that lead to a NPE when persisting objects with components

合并或rebase

这是一个争论，但以下是我的观点。

  • 原始0：不要rebase已公开共享的分支（除非你知道人们不会使用它或你希望他们受到伤害）。
  • 原始1：在假设它不会违反原始0的情况下，优先选择rebase而不是merge。

当您触发pull请求时，这尤其合理：在您分支的分支（通常是master）上rebase。您的工作将更容易阅读和整合。

rebase将您fork的分支（比如master）中的更改置于您所做的新提交（比如HHH-XXX）之下，从而保持历史线性。

git checkout HHH-XXX
git rebase master

在rebase的过程中，您可以将您的提交历史重写以清理注释或将一些提交合并在一起（称为squashing）。

git rebase -i HEAD~6 (go back 6 commits in time)

回滚：cherry-picking

Git使回滚变得有趣。

比如说你在master上做了一些提交，这些提交的sha1分别是ae397d...和87ab342...

您可以很容易地将它们应用到旧分支上。

git checkout 3.5
git cherry-pick ae397d
git cherry-pick 87ab34

咻，你完成了。现在，我告诉你做小提交了吗？这也是为了回滚者。

别名和配置

一旦你厌倦了输入冗长的命令行，就使用别名。我把我的~/.gitconfig文件的副本放在这里，以防人们想要复制包括别名在内的一些内容（见下文）

~/.gitconfig
[user]
     name = Redacted
     email = redacted@redacted.com
     signingkey = id_key.pub
[core]
     editor = open -nW -a Smultron
[merge]
     tool = opendiff
[color]
     ui = auto
[color "branch"]
     current = yellow reverse
     local = yellow
     remote = green
[color "diff"]
     meta = yellow bold
     frag = magenta bold
     old = red bold
     new = green bold
[color "status"]
     added = yellow
     changed = green
     untracked = cyan
[github]
     user = redacted
     token = redacted
[alias]
     co = checkout
     undo = reset --hard
     cb = checkout -b
     br = branch
     cp = cherry-pick

工具

如果您使用Mac OS X，GitX是一个出色的工具。特别是，您可以通过几点击轻松地玩转交互式暂存，并只通过几点击将文件的某些部分提交。一个典型的用例是将打字错误的提交与核心功能的提交分开。有些人喜欢内置的GitK GUI。

通过git-completion.bash支持命令完成，如果您是命令行类型的人，那就相当不错。该脚本可在Git项目源代码和其他地方找到（包括Fedora）。Pro Git关于它有更多信息。

各种

您还可以阅读这篇博客文章，其中包含了一些从SVN迁移到Git的人的更多信息。

这篇文章已经够长了，欢迎在评论区分享您的技巧。

返回顶部