git-团队的合并操作规范

目录

合并操作规范

git版本不一致的理解

合并操作规范

在开发过程中，一旦有一个人更新了代码，并发起了合并请求，管理员就会询问其他人有没有正在更新的代码，如果有，就先对自己正在更新的代码微调一下，使当前写的代码可以正常运行，即使功能没有写完也没关系，然后也发送合并请求。所有修改过项目的人都发起了合并请求后，管理员会将这些请求一起合并，这样，就避免了

• 当一个人合并了代码，其他人拉取时，需要将自己正在修改的代码本地保存来防止拉取最新代码时自己写的代码被覆盖掉。
• 当一个人合并了代码，其他人暂时不拉取，等自己的写完了，也合并上去。等管理员将所有人的合并都通过了，再拉取。这种操作确实可以不受其他先合并的代码的影响，因为不管先合并还是后合并，只要不拉取先合并的代码，那么两者的合并请求都是基于同一个版本，不会产生版本冲突。但是会产生一个问题:现在有两个人在开发项目，小红和小蓝。两人最开始都是基于1.0版本开发的，小蓝开发效率很高，很快就讲代码更新到了2.0版本并合并到了主分支，而小红速度比较慢，自己的代码还没写完，于是，她采取的策略是:先不拉取，等自己的代码写完之后再请求合并。结果，小蓝速度太快，又更新了代码并请求合并到主分支，此时，小蓝的更新是基于2.0版本的更新，然后小红的代码终于写完了，她请求合并，此时，小红的更新却是基于1.0版本的，两个合并基于的版本不一致，那就会产生问题。而采用管理员统一合并代码的方式，可以保证每个人手上的代码基于的版本都是最新的，即:版本是一致的。

git版本不一致的理解

比如在同一个文件，假如前50行是空白的，而在后50行中，a基于的版本是打印123，b基于的版本是打印456，然后A在a版本中的0~25行写了一些代码，B在b版本中的26~50行中写了代码。此时A和B修改的位置不一样，如果他们基于的版本是一样的，是不会起冲突的。但是他们基于的版本不一样，一个后面打印123，一个后面打印456，即使他们写的位置没有冲突，但还是有问题，因为版本不对应。