本地分支领先远程分支,应该怎么正确去操作?要先 pull 还是直接 push --force?

2022-08-09 10:34:33 +08:00
 magic3584

由于昨天码云宕机,今天要提交代码。

刚才进行了如下操作:

  1. 如果直接 pull merge 的话提示没有冲突
  2. 使用 pull --rebase 以后有冲突,但是发现前两天的本地提交都没了。。。这种时候还能找回吗?

这两天遇到好几个非正常的 git 问题,都蒙了

7415 次点击
所在节点    git
84 条回复
han777
2022-08-09 10:38:36 +08:00
git clone 远程分支到一个新文件夹,然后把旧文件夹里修改的代码手动复制粘贴进新文件夹。最后使用新文件夹继续开发,旧文件夹删了。
Jooooooooo
2022-08-09 10:39:02 +08:00
直接 push 的问题是?

你领先远程分支就是因为你有开发啊. 最终都是要 push 到远端的.
magic3584
2022-08-09 10:45:05 +08:00
@Jooooooooo #2
push 之前不都是先 pull 的吗?不知道这次为什么 pull rebase 以后本地的代码也没了。rebase 不是会生成新的 commit 吗?
magic3584
2022-08-09 10:45:55 +08:00
@han777 #1
您这个是一个好办法,如果代码改动太多的话应该也不小工作量吧。有没有更好的办法呢?
Felldeadbird
2022-08-09 10:58:37 +08:00
1. 如果是多人开发,你 push -f 。恰好团队没人做分支管理,你会被骂得很惨。

2. 一般来说,你应该先 git pull 你现在所在的分支(例如 dev )。 如果你是单人开发,那么一般不会报错。不报错就 commit ,push 到远端。
2.1 pull 出错了,这时候说明远端和你本地存在修改同一个文件的问题。这时候有几种做法。这里只介绍我的分支做法
2.2 将当前本地开发好的代码,commit 到一个新的分支。如:dev-20220809 。然后切回远端的分支。pull 一次最新代码。
2.3 在当前的远端分支,再开一个 dev-test-merge 分支并切换过去。然后合并 dev-20220809 ,看看有没有报错。
2.4 由于不清楚你的分支管理策略,一般来说,没啥问题,我就 dev 和 dev-20220809 合并,然后推送到远端的 dev 分支.

3. 这时候其他人 pull dev 分支,也得到你的代码了。
Felldeadbird
2022-08-09 11:00:57 +08:00
2.3.1 补充一点。你 pull 报错的话,你在做 dev-test-merge 和 dev-20220809 合并,有一定可能会提示冲突。这时候你要手动合并代码并解决冲突。也可能 git 帮你合并了同一个文件了。
crysislinux
2022-08-09 11:01:13 +08:00
所以最好从开始就只有你一个人用这个分支。如果需要合作,另外搞一个公共分支。不要几个人在一个分支上直接干活儿。
magic3584
2022-08-09 11:37:59 +08:00
@Felldeadbird #5
pull merge 没冲突,pull rebase 有冲突,这是为啥啊。
您说的这种新建分支再合过去我觉得是合理的,也好理解。

#7
我们都是 dev 开发,然后每个人都有自己的 dev-xx 分支,然后去往 dev 合,就很乱。。。
unco020511
2022-08-09 12:03:16 +08:00
合代码不是应该通过 merge request 吗
nothingistrue
2022-08-09 12:33:49 +08:00
push --force ,你是想死吗。你的 1 和 2 都可以,2 并不是本地提交没了,而是因为冲突(本地和远程改了同一个地方),需要你先解决冲突。新手的话,还是老老实实 pull merge 吧。
xiaoming1992
2022-08-09 12:45:38 +08:00
git fetch remote-branch
fit checkout -b local-branch remote-branch
然后慢慢 cherry-pick
FACEB00K
2022-08-09 12:46:35 +08:00
第二种情况你的本地提交应该是还在的,如果你不想解决冲突的话,用 git rebase --abort 来中止 rebase 。
shawndev
2022-08-09 12:50:52 +08:00
如果你不清楚底层发生了什么。就不要用 cherry pick, rebase 。
如果你不清楚同事的身手脾气。就永远不要--force, --hard 。
xiaoming1992
2022-08-09 12:53:22 +08:00
common -> remote-1 -> remote-2 -> ... remote-branches
|-> local-1 -> local-2 -> ... local-branches

你的这种情况,merge 没冲突,rebase 有冲突,我猜测是 common 后面的前几个本地分支有冲突,后面改过之后没有冲突了,但是 rebase 的时候,git 从 common 一个 commit 一个 commit 比较过去,在前面就发生了冲突。

如果你的本地分支落后的几个 commit 不重要的话,直接 reset --soft 到本地 common commit ,再 rebase ,就不会有冲突了
magic3584
2022-08-09 13:34:35 +08:00
@unco020511 #9
同一个分支的本地和远程

@nothingistrue #10
push --force 是因为远程分支被回滚了,落后了本地分支。用 2 以后本地的提交好多都没了
magic3584
2022-08-09 13:35:33 +08:00
@FACEB00K #12
他们已经解决完冲突 commit 了,所以没法 abort 了,git log 也没找到前几天的本地 commit
magic3584
2022-08-09 13:37:09 +08:00
@shawndev #13
rebase 教程都是合并分支时候,这种远程分支落后的情况下 pull rebase 我确实是蒙了
magic3584
2022-08-09 13:43:19 +08:00
@xiaoming1992 #14
不明白为啥 pull rebase 会丢掉本地的 commit ,rebase 不是会生成新的 commit 吗
nothingistrue
2022-08-09 13:45:24 +08:00
@magic3584 #15 远程分支被回滚,说明远程分支已经被破坏了,这时候就不能做任何 pull ,否则你本地也要跟着被破坏。远程分支回滚后的那个 Head ,它之后的(在回滚前)所有提交,不管是本地的还是远程的,都被搞废了。你们本地需要先留着当前仓库不动,另开位置重新 clone ,然后通过补丁或者复制粘贴,把本地晚于远程 Head 的提交,手动重新提交上去。当然,也可以用 pull --rebase ,它本质上是 rebase -i ,前提是已经对 git 操作尤其是 rebase 相当熟练。
nothingistrue
2022-08-09 13:47:39 +08:00
@magic3584 #18 先 fetch ,你现在本地仓库上的远程仓库引用 origin/master 跟真是的远程仓库 master 分支可能都不一样。这事,建议找熟手帮你做。没有话就别 pull 了,只能手动复制粘贴。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/871607

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX