求教各位大佬，关于 git 的代码合并冲突问题，有点懵

[chaniqure]

我们使用 vue 开发的一个前端项目，有个 dist 的打包目录，项目的 git 包含的这个目录，先不用去管为什么要提交这个 dist 目录。

现在有 a 、b 两个开发人员，a 修改了 1.vue 文件，b 修改了 2.vue 文件，现在 b 编译了项目，生成了新的 dist 目录，进行 git 的 push 操作，成功提交到 gitlab 服务器。现在 a 也进行编译操作，进行 push ，就提示需要更新代码，然后 a 进行 pull ，这时候 dist 目录出现了冲突。

a 的解决冲突的操作，使用 idea 自带的 rollback ，还原了代码，再删除了 dist 目录，进行 commit ，然后从远程 git 服务器 pull 代码，最后 push 。但是这时候，b 修改的 2.vue 的记录就丢失了，这是什么原因？ git 日志里面都找不到 a 修改 2.vue 文件的日志，2.vue 文件还是 b 提交之前的代码，b 这次提交的记录全部就丢失了。

[a1lenyang]

a 进行 rollback 操作后，2.vue 文件被还原成了之前的版本，即 b 提交之前的版本。因此，当 a 从远程 git 服务器 pull 代码时，2.vue 文件被还原成了之前的版本，而 b 提交的新版本就被覆盖掉了

[zihuyishi]

直接 git pull 下来出现冲突，然后重新生成 dist. git add dist, git commit, git push

[Gota]

git log 里都找不到，那八成是 force push 强行覆盖掉了，在仓库设置里把这个分支设置为保护分支可以避免这种情况。

[iOCZ]

a 一开始就 pull 了，rollback 之后，b 在 a 的本地就没了，再 pull 就没有 b 的修改了，虽然远程仓库有 b 。

[error451]

因为 b push 上去的版本，因为冲突 a pull 不下来啊。 所以 a 本地是没有 b 修改的内容。 然后 a 又把自己的版本强推到服务器，自然就把 b 修改的覆盖掉了啊。
正确的做法是，b 把自己本地的 dist 下的内容删除了，再提交一个版本 push 到服务器上去。
然后 a 把自己本地的 dist 下内容删除了，commit 一个新版本，然后再 pull , 这样就生成了一个包含 a , b 修改并且 dist 内容为空的版本， 然后再把这个 push 上去。
千万不要把 dist 加到版本库里去啊，有了冲突根本没法改，这有什么意义呢？ 你完全可以在服务器上加个一个 git-hook ,每当推送了新版本，就自动编译。

[iOCZ]

@error451 因为 a pull 了 b 才发生了冲突，a 本地是有 b 的。

[oneisall8955]

盲猜 a force push 了，不然不会没有版本记录

[shiqueb]

这些只是 a 和 b 的片面之词罢了！众所周知人的记忆会向有利自己的一面变化！
有没有一种可能 a 看到冲突直接 push -f

[chaniqure]

我的所有的操作都是使用 idea 的 git 工具，直接点的按钮去 push 的，看了一下 git 日志，没有 push -f ，可能是我记错了吧

[leonshaw]

去 b 的本地仓库看本地和远程分支

[ivslyyy]

dist 的冲突直接全点接受，或者拒绝，然后再编译一次就行。
不过按道理，
dist 不应该被 git 来管理
不知道是不是我太老了
已经过时了。

[suzic]

解决冲突的方式太暴力了，试试先使用 git rebase 命令暂存本地修改，然后拉取代码，再处理冲突，最后提交。

[statement]

dist 直接不管。不拉不推 重新编译不行吗

[chaniqure]

@ivslyyy 不是你太老了，是我们项目咋说呢，小团队，没有运维人员，就两个 Java 开发，连 vue 前端开发都没得，有 ios 和安卓开发。项目已经上线了，服务器上部署了 Jenkins ，可以直接打包到线上，尝试过直接 Jenkins 服务器编译前端项目，但是 centos 服务器系统版本太老了，node 环境的系统依赖库版本太低了，运行不了，需要系统升级，我们又不敢升级，不得已才这样处理的。

[chaniqure]

@statement 因为终归是要提交的，我可以重新编译，但是应该是先更新了再重新编译才对，当时忘了

[ivslyyy]

@chaniqure 那还是可以分离开，
开发代码用一个仓库
dist 单独做一个仓库给 jenkins 用
开发代码合并之后打算部署的时候
跑一个 bash 脚本就行。
从总的时间成本来讲
这样比每次合并 dist 冲突
要省时间多了。

[chaniqure]

@error451 我也不愿意把 dist 加进去，这个搞出了多少个冲突。因为一些原因服务器没法编译，所以才只能在本地编译好

[error451]

@chaniqure 那也有办法， 新建一个独立的 release 分支。 其他开发者 push 到 dev 分之，dev 分之 dist 是空的。 每次开发完了， 将开发分支合并到 release 分支，然后 release 分支本地编译，push 到远程的 release 分支上去

[guochao]

本地构建以后放到单独的存储里面啊，没必要放到 git 里面，这玩意儿不需要管理版本，只要有一个文件能告诉研发这个构建产物是哪个 reference （ commit/tag ）构建产生的就行。

像是 github 、gitea 、gitlab 、bitbucket 都提供了 repo release 这类功能，就是给你建立一个 release 然后放产物用的。

再不行有个 nfs 、samba 、s3 、nexus 、webdav 什么的都可以放产物嘛。

如果是把 git 当存储，就把构建放到一个单独分支里面。如果存二进制建议再开个 git lfs

[realJamespond]

更新前不应该先 git stash 下？

[chaniqure]

@realJamespond 哈哈，是该这样，就当我当时误操作吧。

[oxromantic]

a 应该被警告并通报案例，如果 a 是 OP 本人就死咬 b 没提交

[chaniqure]

@oxromantic 过分了，哈哈，a 就是我本人啦。而且团队就我们两个后台开发，不是讨论责任问题，还原代码也就十来分钟，主要是讨论 git 和解决方案

[oxromantic]

解决方案很简单，锁定主分支，所有提交走 PR ，两人都同意再 merge