Using Git in Real Projects

Table of Contents

Preface

在这段时间，我实际参与开发了一个项目。在这个过程中，我学习到了一些关于 git 开发的经验，特此做一个记录。

Main

Always branch

除非只是进行一个足够小1 的修改 ，否则一定要新建一个分支来进行开发。

Branch name

分支名字的选择也应该尽心挑选。首先应该根据具体修改的内容命名分支：

  • chore: 很多杂活，比如文档的修改，引入新依赖等……
  • feat: feature 的缩写，开发增加了一个新的功能。
  • fix: fix bug.

How to Merge

不论是个人还是团队开发，在 merge 之前都应该先推送一下分支，然后再 merge。

merge message 也应该填写充足的信息。

  1. title: Merge feat/node-definitions
  2. 空行后再写一句描述，比如 Add zustand store + definitions fetch.

Untrack some files

git rm --cached <file>

in Emacs Magit, you can just type K.

revert commit

revert 不会修改历史 

git revert <commit-hash>
git push origin dev

reset 会修改历史，需要强制覆盖 

git reset --hard <commit-hash>
git push origin dev --force

提交之前记得使用 rebase -i

把修改的记录合并成为每一次提交都是一个完整的有意义的提交。

多人协作开发

本地的开发分支，难免需要同步远端的 main 分支，这个时候我们有需要使用 rebase 把我们的修改插在 main 分支的最新提交记录上面。 

# 1. 切换到 main 分支并拉取最新代码
git checkout main
git pull origin main

# 2. 切换回你的开发分支
git checkout dev

# 3. 执行变基（将 dev 的地基拔起到 main 的最新位置）
git rebase main

# --> 【注意】如果发生冲突，变基过程会暂停。
# 你需要手动解决冲突，然后执行以下命令（注意这里千万不要执行 git commit）：
# git add .
# git rebase --continue
# （Git 会逐个应用你的提交，如果有多个提交冲突，可能需要重复上述解决冲突的步骤）

# 4. 强制推送到远程
# 【核心差异】因为 rebase 改写了本地 dev 的提交历史（底层哈希值变了），
# 如果你的 dev 分支之前已经 push 过，现在直接 push 会报错。必须使用强制推送。
git push --force-with-lease origin dev
# （使用 --force-with-lease 比单纯的 -f 更安全，它会检查是否覆盖了别人推送到 dev 的代码）

没错，直接 rebase 主分支就好，就是这么简单。注意 rebase 如果想要合并到其他分支，必须保留分支时的那个节点。

modify commit

rebase edit

Footnotes:

1

单文件、单行或连续多行的修改。更准确的说是基于 commit 信息和使用 git diff 可以轻松了解修改内容。