level 3
会，本地一定是会有所更改的！本地文件的添加、修改和删除会在这时从远端引入，若文件仅在一侧发生了更改，那么 Git 能够自动地处理这些变化。但是，当文件在两侧同时发生了变化，且变化后状态不同，这时会引起冲突，需要你自行解决冲突（以哪一边为准）。一般情况下，你在本地 Commits 中产生的文件更改不会被 "git pull" 行为覆盖。
2022年02月24日 03点02分
level 12
2
那么远端有差异，本地也有增改，不能用pull命令？
2022年02月24日 06点02分
@tab_98 Pull相当于fetch＋merge，在fetch时 就会出发一次merge，将远端merge到remotes/origin/branch上。完成后你的remotes就已经与远端相同了，再merge一次到branch上
2022年02月24日 10点02分
@Dragon1573 我只有master分支，是不是应该先fetch，然后考虑怎么手动merge？
2022年02月24日 10点02分
@tab_98 你也可以直接pull的，Git遇到解决不了的冲突就会自动弹出默认的编辑器让你人为解决冲突。
2022年02月24日 10点02分
level 12
其实像你这样如此复杂的情况，使用 SourceTree / TortoiseGit / GitKrakan 这一类 GUI 客户端执行 Git 操作会更好，我之前在提交时执行 Cherry-Pick 和 Interactive Rebase 也都是使用 SourceTree / Git Extensions for VSCode / Git Plugin for JetBrains DataSpell 来实现的。GUI 操作更为直观，也有更多的用户交互和确认环节，极大程度地避免了误操作问题的出现。
2022年02月24日 12点02分
4
有道理，有空试试
2022年02月24日 12点02分
@tab_98 不过，不论是 Cherry-Pick （遴选）和 Interactive Rebase（交互式变基）我都极少遇到。遴选主要发生在我连续做了多个小任务却忘了多次提交时，完成不同任务的代码可以借助遴选功能从统一的更改中单独筛选出来（可以精细到特定的行）。
2022年02月24日 12点02分
@tab_98 交互式变基则发生在多次提交把时间线搞乱了的情况，我可以借助这个功能对本地仓库中的提交进行重排序、合并压缩、更改提交信息之类的操作，实现对时间线的美化。
2022年02月24日 12点02分
@tab_98 由于时间线变动，本地必然与远程不同，此时一切以我本地仓库为准，我将使用 "git push --force-with-lease" 安全地覆盖远端，即使远端与本地不同，Git 也不会提示 Pull First 了。
2022年02月24日 12点02分
