这是一个创建于 3540 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如说我 HEAD 跟上游冲突了，我就 `git reset HEAD~`, `git stash`, `git pull origin master`, `git stash pop`, `git add *`, `git commit -m "Bug fix: ..."` , `git push --force fork feature-branch`。
不知道这样和直接 git-rebase 有什么差别…… 反正感觉这样挺顺手的 :-P
不过，早晚都要学会 git-rebase 的用法，虽然不一定是现在。
嗯，`git stash pop` 之后还是要解决一些合并问题的，效果和 `git rebase -i` 有点像。
不知道这样和直接 git-rebase 有什么差别…… 反正感觉这样挺顺手的 :-P
不过，早晚都要学会 git-rebase 的用法，虽然不一定是现在。
嗯，`git stash pop` 之后还是要解决一些合并问题的，效果和 `git rebase -i` 有点像。
 |
1
kenken 2015-04-18 02:43:32 +08:00
stash pop还得解决冲突，直接merge rebase 解决冲突不是一个样子吗
|
 |
2
SharkIng 2015-04-18 05:18:59 +08:00
我都是打开文件，一行行读冲突内容然后修改保存重新Commit :) 笨办法
|
 |
3
msg7086 2015-04-18 07:14:42 +08:00
rebase和你的stash法应该是类似的。只是rebase可以用在多次提交上。
|
 |
4
Xrong 2015-04-18 10:26:17 +08:00
我以为你和别人起冲突了...
|
 |
5
benmaowang 2015-04-18 10:54:35 +08:00
@Xrong +1。看到标题时还莫名想起了分歧终端机。
|
 |
6
9hills 2015-04-18 11:39:46 +08:00 via iPhone
前面都理解，最后的push force 什么鬼
|
 |
7
clino 2015-04-18 11:48:48 +08:00
git rebase origin/master
有冲突上 beyond compare 3路比较,我觉得这是最好的一种方式了,不过其他的我也不会了 |
 |
8
ngn999 2015-04-18 12:55:59 +08:00 via iPhone  1
弄这么多就是 `git pull -r`
|
 |
9
bombless OP @ngn999 哈哈，以前人家也是这样跟我说的 https://github.com/AngryLawyer/rust-sdl2/pull/301#issuecomment-72076800
不过我不熟悉 Git 的工作流程，不一步步来我会慌的 :-） 在我正文描述的步骤中间我经常还要检查几次 git-status 和 git-diff 确保我没有搞错 :-P |
 |
10
mahone3297 2015-04-18 14:46:05 +08:00
冲突的话，git merge或者rebase不好？解决冲突。
你的做法的话，在这一步`git stash pop`也会冲突吧？ ps 主干的话，需要`git push --force`这样去force吗？如果你force的话，是否代表，别人也会冲突？ |
|
11
bombless OP @mahone3297 嗯，主要是保证在上游过编译的前提下我新的提交也是过编译的。
逻辑上还是合并冲突，只不过步骤上分开来了。 合并冲突是在 `git stash pop` 这一步做的没错，这里会出现一些 `<<<<<<<<<<<` 和 `>>>>>>>>>>`，在合并的时候把这些冲突部分处理掉，对正常语言写的代码来说一般就没事。 `git push --force` 我这里的意思是我的 HEAD 这个提交其实已经 push 过了，只不过没有合并到上游的主干，我需要强制性把之前 push 过去的 HEAD 从上游中抹掉。没错如果其他人在依赖我这个 HEAD，那就必须解决新的冲突。所以最好的情况就是代码的模块化比较好，可以保证在没有直接的文件上的冲突的情况下强制性合并。 |
|
12
mahone3297 2015-04-18 22:47:41 +08:00 1
@bombless
》`git push --force` 我这里的意思是我的 HEAD 这个提交其实已经 push 过了，只不过没有合并到上游的主干，我需要强制性把之前 push 过去的 HEAD 从上游中抹掉。没错如果其他人在依赖我这个 HEAD，那就必须解决新的冲突。所以最好的情况就是代码的模块化比较好，可以保证在没有直接的文件上的冲突的情况下强制性合并。 所以，你的做法应该是merge or rebase，这时候，虽然也会有冲突，然后，你resolve conflicts后，push就可以了，不需要 --force，这样，其他人也不会有任何问题。 |
|
13
bombless OP |
|
14
mahone3297 2015-04-18 23:39:41 +08:00
@bombless
假如你的commit是这样 ..................->a->b->c ..................->a->b->c` --amend 的话，代表你丢弃之前的c这个commit，新生成一个c`的commit。这时候，别人如果之前拿了你的c commit，这时候，别人fetch代码，git会提示，branch有问题，开叉了。然后，到底会不会出问题，我好想也不清楚了，要试下。 反正，多人提交的branch（比如master），不要force update，amend，除非万不得已。或者知道别人还都没获取你的commit。你自己开的分支，随便force update。我是这么干的。。。 在master上，我即使提交错了，我也会revert上次错的commit。虽然log看起来有点难看，但是不会有问题。（说明下，我的这个做法可能并不一定好，可能有更好的方法） |
|
15
mahone3297 2015-04-18 23:41:48 +08:00
@bombless
》不过我在想，如果要 amend 到 HEAD 那就必然有冲突，是这样吗？ 好像不一定会有冲突。冲突的意义是说，同一行代码，都被修改了。 上面说的，c和c`，假如这2个commit，没有修改到同一行代码，应该是不会有冲突的。 |
|
16
bombless OP 试了下 `git pull -r` 真的很爽……
做完之后 git-add 然后再 `git rebase --continue` 一切就搞定了…… 看来没有以前想象的那么难嘛 |
Select Language