你们在用 git 合并时但不担心自己操作失误把代码弄丢?

[yuann72]

这几天用 rebase 的 2 个事例

事例 1:

rebase 前的提交历史大概这样:

提交时间	commit message
10:01	A1
10:02	B
10:03	A2
10:04	C

我想把 A1 和 A2 合并, 用 webstorm 进行 rebase:

action	commit message
pick	A1
squash	A2
pick	B
pick	C

然后点 start rebase, rebase 完只剩下 A1, B, C 3 个 commit, 这时 npm 开始报错提示有个文件不存在, 看了 A1 commit 的内容发现这个文件在 A1 commit 里被删了, 但是原本的 A1, A2 commit 里并没有删这个文件 接着就是 git reflog 找回 rebase 前的 commit id, git reset 恢复到 git rebase 前, 再试一次 rebase 还是一样 试了几次后发现下面这样进行 rebase 就能达到我的目的, 只剩下 A1, B, C 3 个 commit, 文件也没丢

action	commit message
pick	A2
squash	A1
pick	B
pick	C

事例 2:

使用 webstorm 右下角 git 分支里的 "Rebase Current onto Selected" 将服务器端的分支内容用 rebase 的方式合并到当前分支 结果合并一半右下角弹出红色感叹号, 报错信息大概这样"文件路径 Permission XXXX", 接着还是 git reflog 找回 rebase 前的 commit id 恢复后再试一次就没报错了 rebase 合并是合并完了, 但我暂存区那些修改完还没提交的文件都不见了! 查了搜索引擎后用 git stash pop 恢复出来

事例 1 可能是我操作失误或文件冲突导致, 也就还好是一个完整的文件被合并丢了, rebase 完立马就发现了, 如果是某几行代码合并丢了, 那以我这的测试程度可能要到生产环境出 bug 报错才会发现。也还好我是提交完 C commit 后就进行 rebase 事例 2 我就担心要是 git stash 里没有我的文件, 或者被我瞎操作把 git stash 清空了那就完了

所以我现在用 git 命令时会很谨慎, 生怕有些代码给我弄丢了. 特别是合并冲突处理文件冲突的时候, 面对这几个月前编辑的代码, 我也不知道哪边的版本是正确的代码

[Felldeadbird]

不会丢代码啊。怕丢就开多 2 个分支各自留底。或者额外开一个临时分支，两者合并。整理好临时分支后，在合并主分支。

[Euthpic]

不担心，合出问题的话可以 revert，或者 merge 前开个 backup branch 。丢代码会出问题，不丢代码难道就不会出问题吗？重要的是有改动的地方测试有没有回归到

[wangsd]

WebStorm 有本地历史记录

[Hstar]

以前团队内有人经常合并出错，我们复盘了下发现都是因为 merge 时根本不看 diff 无脑合并

[bugsnail]

1. 先 commit 再合并
2. 尽量用图形化界面, 如 sourcetree + beyond compare

[fregie]

只要 commit 了，几乎就没什么可能会丢。
应该加自动化测试防止合并分支错误导致的问题

[chenmobuys]

合并时有冲突，就不要强制合并。

[ooxiaoming]

只要 git 了就没有找不到的时候...

[mangoDB]

只要保证操作流程正确，不轻易的 checkout/reset --hard，就不会丢代码。

[LemonK]

养成好习惯就不会有问题。1. 尽量不要两个分支改同一个地方，不要有长时间没合并的分支。2. 合并的时候认真看 diff 。

[oxromantic]

不放心的话，合并代码这种事情交给专人负责，同时兼顾 review 代码

[xingheng]

1. 不能保证 rebase 能一步到位的话就用 cherry-pick
2. 不要轻信那个 GUI 封装的 git 操作，亲力亲为

[Trim21]

你可以新建两个分支进行操作，合并之后 diff 合并之前的 commit…

[pocarisweat]

@msg7086
他理解错了，他以为是 Git 会出 bug，而不是代码库出现 bug

[Huelse]

保持 add .和经常 stash save "..."，就没遇到过问题，除非有个小兔崽子偷偷动我电脑了

[CokeMine]

一般能通过 reflog 找回来

[suzic]

有丢过两次 git reflog 找回了

[QHKZ]

理解 git 数据模型很重要，操作 git 数据历史库唯一完全可控的方式是使用 CLI 而不是使用 GUI 按钮，虽然 CLI 的设计很 horrible 。推荐看一下 linus 在 Google 的 git 推销演讲（ 0 几年的视频）以及 MIT 的 missing.csail.mit.edu 的系列课程，里面推荐的一些资源有一定的帮助。

[EastLord]

我怕别人把我的代码弄丢

[shadowfish0]

害，多人开发时代码统一格式化还是太重要了，很多时候合并冲突我一看满页的空格、换行区别，直接懒得看了跳过，但是有时候往往一些业务修改就混在这里面...搞得代码丢了都不知道