Git
Git 配置文件
Git 配置文件：初次运行 Git 前的配置
用户信息配置
每一次 Git 提交都会用到这些信息
git config --global user.name "John Doe"
git config --global user.email [email protected]
git config --global core.editor "vim" # 默认编辑器
git config --global init.defaultBranch main # 切换默认主分支为 main查看所有配置信息，以及所在地址
git config --list --show-originGit Basics
GIt 基本流程图:
在已存在的目录中初始化 Git 仓库
git init 克隆一个现有的仓库
git clone [url] <新的目录名>跟踪新文件，添加到暂存区
git add 从暂存区到工作区，和上条命令是逆操作
git reset 提交文件到仓库
git commit -m 从仓库到暂存区，和上条 commit 是逆操作
git rest --sort 查看文件状态
git status新建并切换到分支:
git checkout -b testing等同于
git branch testing
git checkout testinggit branch # 查看分支列表
# output:
# * master
# testing删除分支
git branch -d testingGit Example
- 初始化仓库
git init git-exampel- 监测 .git 文件夹的变化，按照 0.5 秒的轮询频率
watch -n .5 tree .git- 在 git-example 下新建 1.txt 文件输入内容 1
echo 1 > 1.txt- 将 1.txt 添加进暂存区，查看 .git 文件变化
git add 1.txt- 将 1.txt 添加到本地仓库，这里把 hook 文件夹删除了，方便我们观察 objects 文件
git commit -m "first commit"- 我们观察
git add和git commit命令下都发生了什么
git cat-file -t 查看该文件的类型（有前缀匹配不用全部输入，取前面几个字符就行）
我们先看 git add 命令下的文件
git cat-file -t d00491 # 查看类型 // 输出 blobgit 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示意图：
- 分支
之前我们的操作都是在 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 指针
- 切换为 master 分支，进行第二次提交
git checkout master
echo 3 > 3.txt
git add 3.txt
git commit -m "third commit"此时 master 和 testing 都在各自分支上进行了版本迭代
现在将 testing分支下的代码合并到 master
git merge testing遇到冲突时如何合并，如对同一个文件同一处地方进行了修改
我们分别在 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 同理即可
- 变基
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- 远程 git remote
远程连接 github 仓库
git init
git add .
git commit -m "initial commit"
git remote add origin [email protected]: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