Git是什么

Git是一个分布式版本控制系统，工作原理如图：

上图展示了 Git 四个核心区域（工作区、暂存区、本地仓库、远程仓库）之间的数据流转关系，箭头和动作对应 Git 命令：

• Workspace（工作区）：本地编辑代码的工作目录，即能直接看到、修改文件的地方；
• Index/Stage（暂存区）：临时存放 “待提交变更” 的中间区域，是工作区和本地仓库的 过渡层；
• Repository（本地仓库）：本地存储完整版本历史的数据库，记录所有提交、分支等信息；
• Remote（远程仓库）：服务器上的共享仓库，比如 GitHub/GitLab，用于多人协作同步。

这里git pull实际上相当与git fetch+git merge，讲远程仓库内容拉取到本地仓库，再执行git merge将远程跟踪分支的内容合并到当前本地分支。图中给出的本地库到工作区的箭头操作是checkout，原因是：

• 这里的checkout一般指检出某一个指定的历史版本或切换分支，以覆盖工作区的内容，常用于切换到某个分支，或者回滚历史版本
• 而merge操作会合并两个分支的提交历史，将差异整合到当前分支，一般用于同步远程分支，或者整合功能到主分支

git reset

修改提交历史，–soft、–mixed（默认）、–hard，这三个选项决定了 reset 对暂存区和工作区的影响

指令	代码库（commit结果）	暂存区 (add结果)	工作区（本地文件）
–soft	回退	保留	保留
–mixed	回退	回退	保留
–hard	回退	回退	回退

总结：soft–>mixed–>hard影响范围逐渐扩大，影响范围为：代码库–>暂存区–>工作区

• git reflog应用，reset可恢复
• 解决冲突
  https://blog.csdn.net/eidolon_foot/article/details/149666264?ops_request_misc=&request_id=&biz_id=102&utm_term=git%E5%A6%82%E4%BD%95%E5%90%8C%E6%AD%A5%E8%BF%9C%E7%A8%8B%E4%BB%93%E5%BA%93&utm_medium=distribute.pc_search_result.none-task-blog-2_allsobaiduweb~default-6-149666264.142^v102control&spm=1018.2226.3001.4187

git push

push指令，执行git push，无参数，表示自动将当前所在分支推送到默认远程仓库的同名分支
如果要推送到指定的分支，需要通过参数指定，如：

git push <远程仓库名> <本地分支名>:<远程分支名>
#eg:
git push origin HEAD:mzfs-2.1.5 

• origin 远程仓库名称
• HEAD 本地分支标识，HEAD 是git的特殊指针，代表当前所在的本地分支
• :分隔符
• mzfs-2.1.5 远程分支名称，即要推送到远程origi仓库的mzfs-2.1.5分支

新建git仓库

平台创建仓库

远程平台创建仓库，如gitlab、gitee或者github等，以gitlab为例：

本地克隆

git clone 远程仓库地址
# 如git clone clone git@gitlab.com:Skye/leon.git

一般项目会有多个分支，克隆之后会在本地创建一个和远程的master或者main同名的分支，如果目标代码不在master或者main分支，需要创建一个本地分支，即：

#创建一个与远程origin/mzfs-2.1.5对应的本地分支
git checkout -b  mzfs-2.1.5 origin/mzfs-2.1.5 

通过git branch -vv可以查看本地分支，及其关联远程分支

git config

git config是git配置的指令，可以通过git config list查看配置列表，常用的配置主要有两个

# 全局配置
git config --global user.name "user_name"
git config --global user.email "email_address.xx.com"
# 本地配置
git config --local user.name "user_name"
git config --local user.email "email_address.xx.com"

全局配置对所有仓库生效，本地配置仅对当前所在库生效

同步远程仓库

同步远程仓库和上游仓库主要有下面步骤：

# 1.查看远程仓库配置
git remote -v

# 2.添加远程仓库
git remote add upstream http://gitlab.dvlp.macrosan.corp:8081/buss/filesystem/disk-fs/zfs/zfs.git

# 2.暂存本地未提交修改
git stash

# 3.拉取上游仓库最新提交
git fetch upstream

# 4.切换到目标分支，合并上游提交到本地
git checkout mzfs-2.1.5
#将上游upstream/mzfs-2.1.5分支内容合并到当前所在分支
git merge upstream/mzfs-2.1.5

# 5. 把本地的 mzfs-2.1.5 分支，推送到远程仓库 origin
git push origin mzfs-2.1.5

# 6.恢复之前暂存的本地修改
git stash pop

upstream——查看和添加远程仓库

在本地仓库目录下，查看远程仓库配置

git remote -v

这里origin即为本地仓库的远程库，upstream表示手动添加的上游主线仓库，如果没有，需要手动添加

添加远程仓库
给本地仓库增加一个远程关联仓库，upstream是一个约定成俗的名字，表示上游仓库，添加以后可以通过git remote -v查看

git remote add upstream http://gitlab.dvlp.macrosan.corp:8081/buss/filesystem/disk-fs/zfs/zfs.git

远程上游仓库地址改变后，可以通过下面的指令修改

git remote set-url upstream <新的上游仓库地址>

修改结果：

stash——暂存本地修改

#可用git stash push -m "mesages"或者git stash save "mesages"加上注释信息
git stash
#加备注
git stash push -m "mesages"

git stash指令用于暂存当前工作区和暂存区中修改的未提交的代码，暂存以后可以通过git stash list查看stash记录

fetch——拉取上游仓库提交

# 拉取上游仓库的的提交、标签等信息到本地，但不合并
 git fetch upstream

git fetch与git pull的区别，

• git fetch upstream仅拉取上游的变更，但不合并；
• git pull 会拉取上游变更并直接合并，相当于git fetch upstream + git merge upstream/当前分支

git fetch之后，本地会产生以upstream为前缀的分支，这个分支是只读的，用于记录上游仓库分支的最新状态，可以通过git branch -r查看远程分支。
git fetch之后，可以通过命令查看上游和本地分支的差异：

# 查看上游 mzfs-2.1.5 比本地 mzfs-2.1.5 多了哪些提交
git log mzfs-2.1.5..upstream/mzfs-2.1.5

merge——合并上游提交

切换到需要同步的本地分支

# mzfs-2.1.5代表需要同步的本地分支名称
git checkout mzfs-2.1.5

执行merge或者reabase

# 将上游仓库的提交merge到本地
git merge upstream/mzfs-2.1.5

# 变基，基于上游仓库嫁接本地的提交
git rebase upstream/mzfs-2.1.5

git fetch upstream之后，本地的mzfs-2.1.5和upstream/mzfs-2.1.5有一定区别，eg:

# 上游分支（upstream/mzfs-2.1.5）的历史：
A → B → C → D （D 是上游最新提交）

# 本地分支（mzfs-2.1.5）的历史（假设有1个本地提交）：
A → B → E （E 是的本地提交）

两者的区别
git merge
合并保留分叉，创建新的合并提交，Git 会找到本地分支和上游分支的共同祖先（本例中是 B），然后将上游的 C→D 和本地的 E 合并，生成一个新的 “合并提交”（M），最终历史如下：

A → B → C → D
      \     \
       E ——→ M （M 是合并提交，记录“合并上游代码”的操作）

git rebase
改写历史为线性，无合并提交，Git 会先找到本地分支和上游分支的共同祖先（B），然后暂时 “剥离” 你的本地提交（E），将本地分支指针先同步到上游最新提交（D），再把的本地提交（E）“重新嫁接” 到 D 之后，最终历史如下：

A → B → C → D → E' （E' 是原 E 提交的“复刻版”，哈希值会改变）

使用场景：

• 若 fork 后无本地提交：merge 和 rebase 效果完全一致，选 merge 更简单（无需考虑强制推送）；
• 如果fork后本地有提交：想保留合并上游的记录，用merge；想让提交历史更简洁，用rebase；
• 如果当前fork的分支有多人使用，应该使用merge，避免使用rebase.

总结：merge是“保留历史的合并”，rebase是“重塑历史的合并”。

push——推送到远程仓库

git push origin