Git 鸭眼网的 git pull 使用法

lgn21st · 2011年12月02日 · 最后由 BreeStealth 回复于 2012年08月23日 · 12627 次阅读

以前自己不讲究 Git 里面的 branch 之间应该怎么 merge,但是受到这里这么多在代码上非常有追求的人的刺激,也开始关注如何才能提交干净整洁的 git commits,贴一份鸭眼网的 git pull 使用法在这里,然后自己收藏 XDXD

https://github.com/yavaeye/yavaeye/wiki

git pull 使用法

用 rebase 尽量减少多余的 merge commit

git pull --rebase

pull 特定分支例

git pull --rebase origin a-black-and-thick-branch

rebase 冲突了,又不喜欢一步一步的 git rebase 怎么办?

git rebase --abort
git reset --hard HEAD
git pull
git status

git merge 使用法

保证清晰的路线图,必须 no fast forward, 例如

git merge --no-ff a-tiny-and-soft-branch

16 个赞

有多少在生产环境用 ruby1.9 的?

无引用文章

Saito #0 2011年12月02日

话说鸭眼的 wiki 都是 ns 写的。一定要召唤 ns 过来布道一下。

以前我也是觉得 rebase 无所谓。不强调 merge --no-ff 的。

lgn21st #1 2011年12月02日

#1 楼 @Saito 召唤 ing,我其实正在查资料弄明白这几条命令的参数到底是在做什么,以及为什么要这么做呢。

fredwu #2 2011年12月02日

我也经常试用 git pull --rebase。如果是大的 feature branch 的话,通常我会 git merge --no-ff,小的 branch(两三条 commit)的话,看情况,也许直接会 rebase master 后再 ff merge。

Rei #3 2011年12月02日

构造干净的 Git 历史线索 http://codecampo.com/topics/379#replies-4

可以看到如果不 rebase 和 --no-ff 的后果

Rei #4 2011年12月02日

git reset --hard HEAD 直接把更改丢啦,要提示工作进度要保留在别的分支

1 个赞

night_song #5 2011年12月03日

大胡子也说过 pull 一定要 rebase...

如果 merge 没有 no-ff 而且 merge 时没冲突的话,就没有 merge commit 了,github network 上就会把两个分支的标签叠在一起,没有反映平行开发的真实情况 ...

小心处理的一个好处是清晰的路线图:同样的 commit 不重复出现,merge 可以看到箭头,有箭头的地方一定是 merge.

另一个好处是 github 的 pull request. pull request 界面中,点 merge 按钮和 merge --no-ff 是等价的,如果本地 merge --no-ff, 也会自动关闭 github 上的 pull request.

不小心处理的话,可能会发生一些奇怪的事情,例如:

在路线图中同样的 commit 出现在两个地方,但是 hash 不一样
merge 的时候同一个冲突很奇怪的要解决很多遍
git blame 发现弄坏代码的人是自己,但那段其实是另一个人写的,比窦娥还冤...

这里面有些和 rebase 的机制有关 (我不敢说全部...). rebase 会将本分支中所有冲突的 commit 都挨个修改一遍,从冲突点开始,本地 commit 的 sha1 hash 都变了。所以只适合在 pull 同一分支时用:这些 commit 只在本地有一份,就不会产生 1 和 3 的情况了。

git 太多内容了,有时出 rp 问题了还觉得自己完全不懂 git, git 也一直在出新功能,可以一直学下去...

附带分享一下我的 ~/.gitconfig , git gl 可以在命令行看到路线图

[alias]
 s = status
 c = commit
 b = branch
 co = checkout
 d = diff
 lg = log -p
 gl = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr,%an)%Creset' --abbrev-commit --date=relative
 l = shortlog -s --
 merge = merge --no-ff

@Rei 是我没写清楚,这里假设本地修改都 commit 了而且处于 rebase 中途...

doitian #6 2011年12月03日

#5 楼 @Rei 本地只要 commit 过 gc 之前都找得回来的,用 git reflog 看

andrew_qx #7 2011年12月04日

#7 楼 @doitian 个人觉得这只是一个找回损失的办法,而不是一个能被依赖的办法,就像你不能说因为文件删了有可能能找回来,就随便删除文件一样

andrew_qx #8 2011年12月04日

也许个人的简单项目还是单线推进比较好,不必太过追求 git 历史清晰

cisolarix #9 2012年08月20日

#6 楼 @night_song 弱弱地问一句,大胡子是谁?

hungyuhei #10 2012年08月20日

#10 楼 @cisolarix check it out https://github.com/wycats

ery #11 2012年08月20日

自从学会rebase以后, 我现在已经不再使用pull啦, 我更喜欢用fetch

cisolarix #12 2012年08月21日

#11 楼 @HungYuHei thanks.

BreeStealth #13 2012年08月23日

其实可以使用 gitflow 这玩意啊,简单明了又直接。

需要登录后方可回复, 如果你还没有账号请注册新账号