当前位置: 首页 > 编程笔记 >

git pull时冲突的几种解决方式(小结)

顾均
2023-03-14
本文向大家介绍git pull时冲突的几种解决方式(小结),包括了git pull时冲突的几种解决方式(小结)的使用技巧和注意事项,需要的朋友参考一下

仅结合本人使用场景,方法可能不是最优的

1. 忽略本地修改,强制拉取远程到本地

主要是项目中的文档目录,看的时候可能多了些标注,现在远程文档更新,本地的版本已无用,可以强拉

git fetch --all
git reset --hard origin/dev
git pull

关于commit和pull的先后顺序,commit——》pull——》push 和 pull——》commit——》push的顺序,两种情况都遇到过代码冲突。解决方法如下:

2. 未commit先pull,视本地修改量选择revert或stash

// 场景
同事 有新提交
我 没有pull -> 修改了文件 -> pull -> 提示有冲突

2.1 本地修改量小

如果本地修改量小,例如只修改了一行,可以按照以下流程

-> revert(把自己的代码取消) -> 重新pull -> 在最新代码上修改 -> [pull确认最新] -> commit&push

2.2 本地修改量大,冲突较多

有两种方式处理

-> stash save(把自己的代码隐藏存起来) -> 重新pull -> stash pop(把存起来的隐藏的代码取回来 ) -> 代码文件会显示冲突 -> 右键选择edit conficts,解决后点击编辑页面的 mark as resolved-> commit&push

-> stash save(把自己的代码隐藏存起来) -> 重新pull -> stash pop(把存起来的隐藏的代码取回来 ) -> 代码文件会显示冲突 -> 右键选择resolve conflict -> 打开文件解决冲突 ->commit&push

另外,由于我是通过IDEA来操作git的,所以显示冲突时,我是在图形化界面操作的示意如下

3. 已commit未push,视本地修改量选择reset或直接merge

// 场景
同事 有新提交
我 没有pull -> 修改了文件 -> commit -> pull -> 提示有冲突

3.1 修改量小,直接回退到未提交的版本(可选择是否保存本地修改)

如果本地修改量小,例如只修改了一行,可以按照以下流程

-> reset(回退到未修改之前,选hard模式,把自己的更改取消) -> 重新pull -> 在最新代码上修改 -> [pull确认最新] -> commit&push

ps:实际上完全可以采取直接merge的方法,这里主要是根据尽量避免merge的原则,提供一种思路

3.2 修改量大,直接merge,再提交(目前常用)

-> commit后pull显示冲突 -> 手动merge解决冲突 -> 重新commit -> push

到此这篇关于git pull时冲突的几种解决方式(小结)的文章就介绍到这了,更多相关git pull冲突内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!

 类似资料:
  • Windows 用tutorial进行的操作 若要进行pull操作,请右击tutorial目录,并选择‘拉取’。 用tutorial进行的操作 在以下画面点击‘确定’。 用tutorial进行的操作 我们看到画面上的警告信息表示自动合并失败。请点击‘关闭’以退出窗口。 用tutorial进行的操作 若您确认变更,请点击‘Yes’。 用tutorial进行的操作 TortoiseGit告诉我们:因"

  • 在上一个页面我们提及到,执行合并即可自动合并Git修改的部分。但是,也存在无法自动合并的情况。 如果远程数据库和本地数据库的同一个地方都发生了修改的情况下,因为无法自动判断要选用哪一个修改,所以就会发生冲突。 Git会在发生冲突的地方修改文件的内容,如下图。所以我们需要手动修正冲突。 ==分割线上方是本地数据库的内容, 下方是远程数据库的编辑内容。 如下图所示,修正所有冲突的地方之后,执行提交。

  • 解决冲突 CVS使用内联“冲突标志”来标记冲突,并且在更新时打印C。历史上讲,这导致了许多问题,因为CVS做得还不够。许多用户在它们快速闪过终端时忘记(或没有看到)C,即使出现了冲突标记,他们也经常忘记,然后提交了带有冲突标记的文件。 Subversion通过让冲突更明显来解决这个问题,它记住一个文件是处于冲突状态,在你运行svn resolved之前不会允许你提交修改,详情见“解决冲突(合并别人

  • 两个客户端同时修改同一个文件, 改动同一个位置,发生冲突情况。 这时如果一个用户使用commit 提交文件就会提示已经过时(out of date): 说明另一个人可能被别人改动过! 这时需要update更新该文件,更新后效果如下:     db.properties 将本地和服务器合并到一起的文件 (不要直接看)     db.properties.mine 我本地自己修改后的文件      d

  • 上一章介绍了Git协议,并且使用本地协议来模拟一个远程的版本库,以两个不同用户的身份检出该版本库,和该远程版本库进行交互——交换数据、协同工作。在上一章的协同中只遇到了一个小小的麻烦——非快进式推送,可以通过执行PULL(拉回)操作,成功完成合并后再推送。 但是在真实的运行环境中,用户间协同并不总是会一帆风顺,只要有合并就可能会有冲突。本章就重点介绍冲突解决机制。 3.2.1. 拉回操作中的合并

  • 问题内容: 假设我们有一个包含一个类的软件包(以及其他类)。 然后,我们还有另一个包含一个类的包(显然具有不同的行为)。 现在假设我们需要com.example1中的每个类和com.example2中的Hello类 在这种情况下,哪个被叫? 还是这会产生编译错误? 出于好奇,这只是一个理论问题。 由于创建软件包是为了避免命名冲突,所以当两个软件包包含两个具有相同名称的类时会发生什么? 问题答案: