Git

Git

Git 配置文件

Git 配置文件：初次运行 Git 前的配置

用户信息配置

每一次 Git 提交都会用到这些信息

git config --global user.name "John Doe"
git config --global user.email [e-mail]
git config --global core.editor "vim" # 默认编辑器
git config --global init.defaultBranch main # 切换默认主分支为 main

查看所有配置信息，以及所在地址

git config --list --show-origin

Git Basics

GIt 基本流程图:

在已存在的目录中初始化 Git 仓库

git init <filename>

克隆一个现有的仓库

git clone [url] <新的目录名>

跟踪新文件，添加到暂存区

git add <files>

从暂存区到工作区，和上条命令是逆操作

git reset <files>

提交文件到仓库

git commit -m <message>

从仓库到暂存区，和上条 commit 是逆操作

git rest --sort <files>

查看文件状态

git status

新建并切换到分支:

git checkout -b testing

等同于

git branch testing
git checkout testing

git branch # 查看分支列表
# output: 
# * master
#   testing

删除分支

git branch -d testing

Git Example

1. 初始化仓库

git init git-exampel

2. 监测 .git 文件夹的变化，按照 0.5 秒的轮询频率

watch -n .5 tree .git

3. 在 git-example 下新建 1.txt 文件输入内容 1

echo 1 > 1.txt

4. 将 1.txt 添加进暂存区，查看 .git 文件变化

git add 1.txt

5. 将 1.txt 添加到本地仓库，这里把 hook 文件夹删除了，方便我们观察 objects 文件

git commit -m "first commit"

6. 我们观察 git add 和 git commit 命令下都发生了什么

git cat-file -t 查看该文件的类型（有前缀匹配不用全部输入，取前面几个字符就行）

我们先看 git add 命令下的文件

git cat-file -t d00491 # 查看类型 // 输出 blob

git cat-file -p d00491 # 查看文件内容 // 输出 1

查看 git commit 命令后生成的文件

git cat-file -t 38fd29
git cat-file -p 38fd29
git cat-file -t 89bec1
git cat-file -p 89bec1

示意图：

7. 分支

之前我们的操作都是在 master 分支上进行的，查看一下 master 分支的 head 指向，可以看到指向了最新的 commit object

现在我们新建一个 testing 分支，并切换到 testing，查看其head指向

可以看到和 master 分支指向的 commit object 一样

git checkout -b testing
cat .git/refs/heads/testing

在 testing 分支下进行 git add git commit 操作

查看 testing 的 head 指向，可以看到testing 分支的 head 指向了最新的一个 commit object

cat .git/refs/heads/testing
git cat-file -p 7e2f6

多了以个指向前一个版本 commit object 的 parent 指针

8. 切换为 master 分支，进行第二次提交

git checkout master
echo 3 > 3.txt
git add 3.txt
git commit -m "third commit"

此时 master 和 testing 都在各自分支上进行了版本迭代

现在将 testing分支下的代码合并到 master

git merge testing

9. 遇到冲突时如何合并，如对同一个文件同一处地方进行了修改

   我们分别在 master 和 testing 分支 修改 1.txt 文件

echo 3 > 1.txt
git add 1.txt
git commit -m "fifth commit"

git checkout testing
echo 3_1 > 1.txt
git add 1.txt
git commit -m "sixth commit on testing"

这时我们在合并就会出现合并冲突

git merge testing 
# output:
# Auto-merging 1.txt
# CONFLICT (content): Merge conflict in 1.txt
# Automatic merge failed; fix conflicts and then commit the result.

打开冲突文件手动修改文件，删除掉 <<<< ===== >>>> 等标记，手动修改成想要合并的代码

修改成

git add 1.txt
git commit -m "7 commit"

如果 testing 想要合并 master 同理即可

10. 变基

git rebase 是合并分支的另一种方式，是团队合作中更受推崇的方式

# master 中添加了 6.txt
git checkout -b rebase-branch
echo 7 > 7.txt
git add 7.txt
git commit -m "7.txt"
git rebase master

11. 远程 git remote

远程连接 github 仓库

git init
git add .
git commit -m "initial commit"
git remote add origin [e-mail]:Junhiee/Anitale-Vue.git
git push -u origin main

如果仓库上有文件可能会导致 push 报错：常见报错解决问题如下

pull 分支报错 fatal: Need to specify how to reconcile divergent branches

fatal: The current branch master has no upstream branch.

Git中fatal: refusing to merge unrelated histories

Git workflow

分支管理

develop/ ：开发者分支

feature/： 新功能开发

• 分支来源：develop
• 合并到分支：develop

bugfix/：问题修复

release/： 从 development 分支拉取，不应该开发新功能，只有错误修复、文档生成等面向发布的任务，最终合并到 main 分支。在 main 分支的 commit 中打上 tag

• 分支来源：develop
• 合并到分支：develop、main

hotfix/ ：紧急线上故障修复，也就是 main 分支，更新完后应该合并到 develop 和 main 分支或者当前的 release 分支

• 分支来源：main
• 合并到分支：develop、 main

chore/：依赖升级代码重构

Github Flow

GitHub flow是一个轻量级的、基于分支的工作流。它只保留一条长期主分支 main，所有新功能、修复或实验都在独立的短生命周期分支 feature/* 上进行，适合小团队快速交付

示例

前置条件：创建一个 github 远程仓库

git checkout -b feature/hello
git add main.py 
git commit -m "feat: hello example"
git push origin feature/hello

提交之后 github 就会有提示，根据提示操作审核通过就可以创建 feature/hello 分支，也就是发起一个 pr (pull request)，这个新分支就会多一个 main.py 文件

然后在 pull request 页码就可以选择合并 feature/hello 到 main 分支，切回 main 分支 git pull 拉取最新代码

在本地合并

git checkout -b feature/hello
git add main.py
git commit -m "feat: hi v2!"
git checkout main
git merge --no-ff feature/hello
git push origin main

参考

gitflow-workflow

Git 分支管理策略总结

Git Flow: A Successful Git branching model