活版印字

梳理一下标准流程：

一、正常的工作流程（避免冲突）

1. 初次获取仓库（只需一次）

git clone <仓库地址>
cd <仓库目录>

之后就不需要再 clone 了，直接进入已有的本地仓库目录工作。

2. 每次开始工作前，先同步远程最新代码

git pull --rebase origin master

或者普通的合并方式：

git pull origin master

推荐使用 --rebase 保持线性历史，减少不必要的合并提交。

如果远程没有更新，git pull 会直接告诉你已经是最新的。

3. 修改文件，然后提交

git add .
git commit -m "描述你的修改"

4. 推送前（可选）检查状态

git log --oneline --graph --decorate --all -20

或者更简单地：

git status

确认本地和远程是否分叉。如果 git pull 之后没有再出现新的远程提交，通常不会分叉。

5. 推送到远程

git push -u origin master

• -u 参数只在第一次推送时需要，用来设置上游分支，之后可以直接 git push。
• 如果远程没有新提交，你的推送一定是快进（fast-forward），不会报错。

二、如果推送时遇到“non-fast-forward”错误

这说明远程有本地没有的提交，也就是远程在你上次拉取后又有了新提交（别人推的，或者你在 GitHub 网页上操作产生的）。此时需要先整合远程的提交。

解决方法（推荐 rebase）

1. 拉取远程提交并变基

   git pull --rebase origin master
   

   • 这个命令会自动把远程的提交拉下来，然后把你的本地提交“嫁接”到远程最新提交之后。
   • 如果没有冲突，命令会顺利结束，此时你的本地历史已经包含了远程提交，且你的提交在最新位置。
   • 注意：如果 git pull --rebase 已经成功完成，就不需要再执行 git rebase --continue。

2. 如果出现冲突，Git 会暂停并提示冲突文件。你需要：

   • 手动编辑冲突文件，删除冲突标记（<<<<<<<、=======、>>>>>>>），保留正确内容。
   • 执行 git add <冲突文件> 或 git add . 标记为已解决。
   • 继续变基：

     git rebase --continue
     

   • 重复直到变基完成（提示 “Successfully rebased and updated refs/heads/master.”）。

3. 推送

   git push origin master
   

   此时因为本地已经包含了远程的所有提交，是快进推送，不会报错。

三、澄清你的表述

你说：“如果遇到有其他人基于某分支的提交，导致我们拉取的版本在提交时会弹出冲突，即两个提交都基于同一分支提交，就先变基git pull –rebase origin master，然后git rebase –continue，最后git push -u origin master？”

这里有一个小误区：

• git pull --rebase origin master 本身就会执行变基操作。如果变基过程中出现冲突，它不会自动完成，而是停下来让你解决冲突。解决冲突后你需要执行 git rebase --continue 来继续变基。
• 所以顺序是：
  1. git pull --rebase origin master （可能因冲突而暂停）
  2. 解决冲突 → git add .
  3. git rebase --continue
  4. git push origin master （不需要再加 -u，除非是第一次推送该分支）

如果 git pull --rebase 没有冲突，它就直接完成了，不需要 git rebase --continue。

四、总结推荐的标准工作流

# 1. 进入仓库目录（不是每次clone）
cd your-repo

# 2. 同步远程最新代码
git pull --rebase origin master

# 3. 修改文件...

# 4. 提交
git add .
git commit -m "你的提交信息"

# 5. 推送
git push origin master   # 第一次可用 git push -u origin master

如果推送时发现被拒绝（因为远程有新提交），回到第2步执行 git pull --rebase 再推送。

这样就能避免绝大多数“非快进”错误，也能保持提交历史整洁。