这是一个创建于 1911 天前的主题，其中的信息可能已经有所发展或是发生改变。
假如 A，B 两人同时在 dev 分支上协作开发，当 A 开发完并 push 到远端后，这时候 B 想 push 的话是不是得先 pull 解决完冲突才能 push ？
 | 1 amwyyyy 2020-07-20 09:52:20 +08:00  1 那必须的，后提交的人解决冲突。正常流程 commit -> pull -> 有冲突解决冲突，没就直接 push |
 | 3 ruanimal 2020-07-20 09:59:42 +08:00 1 你试下就知道了，这种情况你不先 pull 合并改动，根本 push 不了 |
 | 4 xuxian 2020-07-20 10:02:04 +08:00 2 个人觉得更好的做法是 git rebase，有空的话可以去了解下 |
 | 5 Exin 2020-07-20 10:03:14 +08:00 1 通常是 git pull --rebase 流行的 git GUI 软件还会在你 push 前自动把你尝试 pull |
 | div class="fr"> 6 apporoad 2020-07-20 10:07:37 +08:00 1 有 2 种方式，一种是本地先 commit 然后 pull，还有只用是 先 stash 然后 pull，在 stash 出来 |
 | 7 edk24 2020-07-20 10:24:52 +08:00 1 add commit if pull == 冲突 { 解决冲突 push } else { push } |
 | 8 LostPrayers 2020-07-20 10:41:44 +08:00 1 个人做法: 使用海龟 git 先拉取(pull --no-rebase),没冲突即可直接提交+推送 有冲突先把本地修改暂存(stash),继续拉取,然后弹出贮藏, 本地解决完冲突后,提交+推送 优点是, 不会轻易覆盖别人的提交,自己的代码改动自己负责。 因为之前见过很多人都是先本地提交了再拉取，然后解决冲突的时候就会把不是自己写的那部分代码弄得一团乱 |
 | 9 ypcs03 2020-07-20 10:45:16 +08:00 1 所以出现这种情况尽量拆成小的 commit 提交，不要攒一堆，解决 conflict 能让你发狂 害怕不小心改了逻辑 |
 | 11 zhw2590582 2020-07-20 11:01:58 +08:00 2 这是正常做法，我就时不时 pull 一下，以防万一后面发生大的冲突 |
 | 12 IceBear05 2020-07-20 11:16:18 +08:00 2 只要两个人不改相同的文件就行 |
 | 13 Areial 2020-07-20 11:39:17 +08:00 先 fetch,再 rebase |
 | 14 ClarkAbe 2020-07-20 12:32:06 +08:00 via iPhone |
 | 15 airlam 2020-07-20 14:02:11 +08:00 $ git push -f 简单方便，不过楼主千万别这么干 |
 | 16 r00t 2020-07-20 14:24:34 +08:00 一条神奇的命令：git config --global pull.rebase true |
 | 17 wuhhhh 2020-07-20 14:27:11 +08:00 git 做操作之前最好都 pull 一下，不然有时候报错就是因为代码没合并的问题导致的。 |
 | 18 learningman 2020-07-20 15:23:44 +08:00 @ruanimal 然后你就会发现你的队友 push 不了加个-f 开开心心走了 |
| 19 ruanimal 2020-07-20 16:24:09 +08:00 @learningman 分支不 protect 吗... |
 | 20 Chieh 养成习惯 commit 前都 pull 一下，要不有些客户端还会自动生成一个 commit，如果你们不在乎 commit 内容那就无所谓 |
 | 21 phobal 2020-07-20 22:04:35 +08:00 我在我们团队推崇的做法是： dev 为主线，各自从该分支切自己的 feature （比如 feature/a, feature/b ）,各自开发完后，提交 MR （ merge request ），通知 reviewers 进行 review， 改问题、改冲突（如果有），切到 dev, 然后 pull , 再切到 feature 分支，执行 git rebase dev， 再 push, 等待 merge ！ |
Select Language