Git 鸭眼网的 git pull 使用法

lgn21st · 发布于 2011年12月02日 · 最后由 BreeStealth 回复于 2012年8月23日 · 9373 次阅读
3

以前自己不讲究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
共收到 14 条回复
243

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

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

3

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

188

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

1

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

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

1

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

96

大胡子也说过 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.

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

  1. 在路线图中同样的 commit 出现在两个地方, 但是 hash 不一样
  2. merge 的时候同一个冲突很奇怪的要解决很多遍
  3. 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 中途...

186

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

96

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

96

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

3253

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

594

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

96

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

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