Git冲突, 大约是每个开发者于团队协作期间都会碰到的“老相识”, 它实质上是好多人同时对同一文件的同一区域做修改时, Git没办法自行判定该保留谁的代码进而出现的冲撞, 虽说并无致命影响, 然而处理不妥当的话, 可能遮挡他人的劳动成果, 甚至致使项目进度被拖慢, 领会冲突的形成缘由以及修复的逻辑道理, 属于高效协作所必须修习的课程。

冲突是怎么冒出来的

最为典型的场景在于, 有两个人拉取了同一个分支, 并且各自针对同一个文件的同一行进行了修改。举例来说, 你与同事都在修改index.html里的一行按钮文字, 你将其改成了“提交订单”, 而他把它改成了“立即购买”。当你们先后往远程分支推送时, 后推送的那个人就会收到冲突提示。除此之外, 在合并分支之际，要是基线上存在差异较大的改动, 同样会引发冲突。使用Git时, 具备将冲突区域标记成特殊格式的功能, 在其被标记的这种特殊格式里边, 所包裹着的部分便是冲突内容, 并且在冲突内容的中间位置, 会以=======来划分分隔开双方版本。

还有一个容易被忽视的触发引发因素是rebase操作, 当你将功能分支变基到主分支之际, 要是两个分支都针对同一处区域存在修改, rebase进程就会暂停下来并给出冲突提示, 在这种状况之下, 冲突的解决思路和合并相近似, 然而修复之后需要运用git rebase --continue去延续变基进程, 而不是直接进行提交。

手把手解决冲突代码

察觉到冲突出现之后, 首要步骤是运用git status去查明哪些文件处于“both modified”这种状态 , 接着将这些文件打开, 寻觅到Git所标记的区域 , 以index.html作为例子, 冲突的部分会呈现成如此这般:

<<<<<<< HEAD提交订单=======立即购买>>>>>>> feature/btn-fix

HEAD表征当前所在分支的版本, feature/btn - fix是正被合并进来的分支版本所指, 你要遵从业务逻辑决定所要留下之物哪一部分 , 最为简易的做法便是径直去掉标记行, 仅留存你期望的那部分代码, 也能够手动编制成崭新之意, 好比把两个版本予以整合: 提交订单／此刻着手购进, 编校完毕之后将文件予以存储。

随后开展git add 文件名的操作, 向Git表明此文件的冲突已被处理。留意千万别运用git commit直接去递交, 由于在冲突状态时提交会被制止。万一你是借由合并引发的冲突, 于执行git commit之后, Git会自行生成一条预设的合并提交信息, 要是你处于rebase进程里, 得借助git rebase --continue去达成变基，最终务必要记得进行git push推送至远程仓库, 以使团队同步你的修复！

在团队协作这个情境当中, 要养成这样一种习惯, 那就是在拉取代码先前的时候, 要先通过git stash把本地所做出的改动进行暂存, 拉取完之后, 再利用git stash pop将此前暂存的改动恢复过来, 像这样的好习惯, 能够极大程度地减少那些本不必要出现的冲突迹象。当遭遇到比较复杂的冲突状况之时, 建议直接跟那些相关的同事进行面对面交流沟通, 在确认清楚彼此意图之后, 再着手去进行修改操作, 以此来避免因为一方不能够理解另一方的逻辑思路从而删错代码的情况发生。任何采取强迫合并或者强行覆盖的做法, 都会为后续埋下潜在的隐患问题。

否玩代码编辑 https://www.fouwan.com