git基础

蔚落 2023-03-03 06:27 14阅读 0赞

git  
本质上是一个版本控制系统。  
包括内容提交，历史记录，基于历史记录的回滚操作等，同时通过远程仓库实现协同开发。

两种版本控制系统  
中央式：  
只有一个远程仓库，必须不断提交或拉取远程仓库代码。典型的如svn  
分布式：  
除了远程仓库外，团队成员的机器山都有一份本地仓库，可以再本机器山提交代码，查看版本，切换分支等。典型的如Git。

Git的4区1堆和5态  
参考：[http://www.mamicode.com/info-detail-2428030.html][http_www.mamicode.com_info-detail-2428030.html]  
四个区：  
工作区 ：开发人员开发时直接操作的区域  
暂存区 ：执行Git add,已修改的代码从工作区进入暂存区  
本地仓库：执行Git commit后，已修改的代码存暂存区进入本地仓库  
远程仓库：执行Git push后，已修改的代码从本地仓库进入远程仓库

1堆 ：  
假设你正在开发一个功能f1，突然来了个更急的需求f2，现在这个功能的代码仅仅开发了一半，此时不完整且没测试，不能commit，但是这个代码又确实有用，这个时候就可以把代码放到堆中。  
Git stash，自动把工作区当前的修改放到堆上。对应名称是上次 commit的信息  
或  
Git stash save "message"  
假设紧急需求f2开发完毕了，现在继续开发f1。  
Git unstash pop  
或  
git stash pop stash@\{$num\} ，比如应用并删除最新的stash：git stash pop stash@\{0\}

五个状态：  
未修改(Origin)  
已修改(Modified)&未追踪(Untracked)  
已暂存(Staged)  
已提交(Committed)  
已推送(Pushed)

顺序操作  
第零步：工作区与暂存区、本地仓库、远程保持一致  
第一步：文件增删改，变为已修改状态，工作区与别的区不一致。  
第二步：git add ，变为已暂存状态  
$ git add --all \# 当前项目下的所有更改  
$ git add . \# 当前目录下的所有更改  
$ git add xx/xx.py xx/xx2.py \# 添加某几个文件  
第三步：git commit，变为已提交状态,此时修改到了本地分支  
$ git commit -m"<这里写commit的描述>"  
第四步：git push，变为已推送状态，此时修改提交到了远程分支  
$ git push -u origin master \# 第一次需要关联上  
$ git push \# 之后再推送就不用指明应该推送的远程分支了  
$ git branch \# 可以查看本地仓库的分支  
$ git branch -a \# 可以查看本地仓库和本地远程仓库(远程仓库的本地镜像)的所有分支

撤销操作  
已修改，但未暂存  
$ git diff \# 列出所有的修改,检查工作区与暂存区的差异  
$ git diff xx/xx.py xx/xx2.py \# 列出某(几)个文件的修改

$ git checkout \# 撤销项目下所有的修改  
$ git checkout . \# 撤销当前文件夹下所有的修改  
$ git checkout xx/xx.py xx/xx2.py \# 撤销某几个文件的修改  
$ git clean -f \# untracked状态，撤销新增的文件  
$ git clean -df \# untracked状态，撤销新增的文件和文件夹

已暂存，未提交  
这个时候已经执行过git add，但未执行git commit，但是用git diff已经看不到任何修改。  
因为git diff检查的是工作区与暂存区之间的差异。  
$ git diff --cached \# 这个命令显示暂存区和本地仓库的差异

$ git reset \# 暂存区的修改恢复到工作区  
$ git reset --soft \# 与git reset等价，回到已修改状态，修改的内容仍然在工作区中  
$ git reset --hard \# 回到未修改状态，清空暂存区和工作区  
说明：git reset --hard 操作等价于 git reset 和 git checkout 2步操作  
注意：此时 Git reset后不需要加 head^等

已提交，未推送  
执行完commit之后，会在仓库中生成一个版本号(hash值)，标志这次提交。之后任何时候，都可以借助这个hash值回退到这次提交。  
$ git diff <branch-name1> <branch-name2> \# 比较2个分支之间的差异  
$ git diff master origin/master \# 查看本地仓库与本地远程仓库的差异

$ git reset --hard origin/master \# 回退与本地远程仓库一致  
$ git reset --hard HEAD^ \# 回退到本地仓库上一个版本  
$ git reset --hard <hash code> \# 回退到任意版本  
$ git reset --soft HEAD^ \# 回退且回到已修改状态，修改仍保留在工作区中。  
注意：此时后面一定要加head^等  
HEAD^ 表示上一次的commit，也可以写成HEAD~1  
如果撤回两次之前的，可以使用HEAD^^或者HEAD~2

已推送到远程  
$ git reset --hard <版本号> \#先在本地分支做回退  
$ git push -f orgin master \# 强制覆盖远程分支  
$ git push -f \# 如果之前已经用 -u 关联过，则可省略分支名  
慎用，一般情况下，本地分支比远程要新，所以可以直接推送到远程，但有时推送到远程后发现有问题，进行了版本回退，旧版本或者分叉版本推送到远程，需要添加 -f参数，表示强制覆盖。  
参考：[http://www.mamicode.com/info-detail-2428030.html][http_www.mamicode.com_info-detail-2428030.html]

Git为什么需要暂存区？  
Commit操作是将暂存区的内容全部提交，所以我们要回到暂存区中思考；从工作区到暂存区，使用Git Add 文件名，我们可以选择性地向暂存区添加内容，然后将其分批提交，暂存区的意义是它将你准备提交的内容分批整体处理；

多分支合并的操作  
场景：将branch1中的修改合并到branch3中  
1）拉取更新提交法  
本地分支切换到branch3： git checkout branch3  
保证本地branch3是最新的：git pull  
将branch1的修改拉到本地brnahc3：git pull origin branch1  
注意此过程可能存在冲突，那么需要修改和处理所有的冲突文件 ，然后执行 git add -u和git commit -m "message"提交。  
注意：此时你的本地仓储中的branch3就是合并后的代码了  
将brnach3的修改推到远程仓库：git push

2）merge  
切到brnach1：git checkout branch1  
将远程branch1中的更新拉到本地：git pull origin branch1  
本地切到branch3：git checkout branch3

拉取最新代码 Git pull origin branch3  
本地branhc1中已经commit的更新合并到本地branch3：git merge branch1  
将本地最新的branch3提交到远程：git push

3）rebase  
参考：[https://blog.csdn.net/tanga842428/article/details/53155860][https_blog.csdn.net_tanga842428_article_details_53155860] Git的rebase与reset  
初始版本为master0，第一次提交后变成了master1；master1为起点，创建了另一个分支test。这个时候，我们分别对master分支、test分支作两次提交，此时版本库应该成了这个样子：  
master0（初始化后的版本）  
||  
v  
master1===test0==>test1===>test2  
||  
v  
master2===>master3  
那么。如果我要让test分支从test0到test2之间所有的改变都添加到master分支来，使得master分支包含test分支的所有修改。这个时候就要用到git rebase了。  
切换到master分支，然后运行下面的命令：  
git rebase test

rebase和merge方式对比  
[https://blog.csdn.net/aroundme/article/details/51223687][https_blog.csdn.net_aroundme_article_details_51223687]

[https://www.jianshu.com/p/dc367c8dca8e][https_www.jianshu.com_p_dc367c8dca8e]  
merge和rebase本质对比：  
现在我们有这样的两个分支,test和master，提交如下：  
         D---E test  
         /  
A---B---C---F--- master  
在master执行git merge test,然后会得到如下结果：  
           D--------E ----    test  
         /                   \\  
A---B---C---F----G--- master  
merge操作会生成一个新的节点G，G是基于F快照增加了test中D和E提交的内容，之前的提交分开显示。如果merge过程中出现了冲突，需要你逐个解决，解决冲突后重新commit。

在master执行git rebase test，然后得到如下结果：

D--------E ----    test  
         /                     
A---B---D---E---C‘---F’---  master  
而rebase操作不会生成新的节点，是将两个分支融合成一个线性的提交。过程如下：  
1）获取test的新commit：首先会切换到test分支，从E开始向前查找，直到找到和master分支最近的一个相同commit快照，会找到B，然后B-E之间所有commit生成patch文件。同时取消test分支中的提交记录。  
2）自动切换分支到master，获取所有master上从B开始的新提交，也声称patch文件。

3）将1）中得到的patch文件应用到master分支。这一步不会产生任何冲突。然后将2）中生成的patch文件应用到master。

注意这里因为是在master新生成的E快照上修改，而原本patch是基于B快照生成的，所以如果F和E中都修改了同一个文件，此时可能会有冲突，会中断rebase,同时会提示去解决冲突。  
处理好了，可以运行git rebase –continue继续直到完成  
如果你不想处理，你还是有两个选择，一个是放弃rebase过程（运行git rebase –abort），另一个是直接用test分支的取代当前分支的（git rebase –skip,慎用，这样会丢失原master分支内容）。

4） 维护master 的HEAD,移动到E’

rebase篡改历史的实际操作演示与验证。

rebase找回丢失内容的方法（未验证）：[https://www.jianshu.com/p/48c9644e4bb6][https_www.jianshu.com_p_48c9644e4bb6]

想要更好的提交树，使用rebase操作会更好一点。这样可以线性的看到每一次提交，并且没有增加提交节点。Git rebase详解  
[https://blog.csdn.net/j3t9z7h/article/details/85241850][https_blog.csdn.net_j3t9z7h_article_details_85241850]  
1 合并多次commit  
最近有两次提交(commit)，但是为了同一个功能，所以想在push之前合并两个commit为一个。  
1）开始合并，执行：git rebase -i HEAD~2  
然后会自动进入vi编辑器模式，示例如下，其上面是你多次commit的记录，下面是注释了的指令说明，如下：  
pick 35a91b2a6 删除无效内容  
pick 8b2334b79 删除无效内容2

\# Rebase 13fb12f8c..8b2334b79 onto 13fb12f8c (2 commands)  
\#  
\# Commands:  
\# p, pick <commit> = use commit  
\# r, reword <commit> = use commit, but edit the commit message  
\# e, edit <commit> = use commit, but stop for amending  
\# s, squash <commit> = use commit, but meld into previous commit  
\# f, fixup <commit> = like "squash", but discard this commit's log message  
\# x, exec <command> = run command (the rest of the line) using shell  
\# d, drop <commit> = remove commit  
\# l, label <label> = label current HEAD with a name  
\# t, reset <label> = reset HEAD to a label  
\# m, merge \[-C <commit> | -c <commit>\] <label> \[\# <oneline>\]  
说明：上面默认对所有的commit都是pick操作，实际我们需求应该是，第一个pick 别的squash即可合并。操作指令解释如下：  
pick：保留该commit（缩写:p）  
reword：保留该commit，但我需要修改该commit的注释（缩写:r）  
edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）  
squash：将该commit和前一个commit合并（缩写:s）  
fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）  
exec：执行shell命令（缩写:x）  
drop：我要丢弃该commit（缩写:d）

所以讲上面两行修改为：  
pick 35a91b2a6 删除无效内容  
squash 8b2334b79 删除无效内容2

2）.执行esc 和 wq 保存  
如果保存的时候，碰到了这个错误：  
error: cannot 'squash' without a previous commit，注意不要合并先前提交的东西，也就是已经提交远程分支的纪录。  
如果你异常退出了 vi 窗口，不要紧张：git rebase --edit-todo  
rebase这时候会一直处在这个编辑的模式里，我们可以回去继续编辑，修改完保存一下。  
git rebase --conitnue 会进入commit对应注释的处理，就是可以修改你提交到本地仓库时的注释，  
然后 退出就会自动提交  
get rebase --abort 放弃rebase

3） 修改注释，上面第一次wq后会进入修改注释页面，如下：  
\# This is a combination of 2 commits.  
\# This is the 1st commit message:

删除无效内容

Change-Id: Ic231a4994fde2f61006ea9efc75f85b1d462f07c

\# This is the commit message \#1:

删除无效内容2

Change-Id: I11000e2bc266795651aff311fd5c71002f369843

\# Please enter the commit message for your changes. Lines starting  
\# with '\#' will be ignored, and an empty message aborts the commit.  
\#

因为这里我们只需要一个commit注释，所以修改成下面内容：  
\# This is a combination of 2 commits.  
\# This is the 1st commit message:

删除无效内容

\# Please enter the commit message for your changes. Lines starting  
\# with '\#' will be ignored, and an empty message aborts the commit.  
\#  
\# Date: Tue Jul 7 08:56:39 2020 +0800  
\#  
\# interactive rebase in progress; onto 13fb12f8c  
\# Last commands done (2 commands done):  
\# pick 35a91b2a6 删除无效内容  
\# squash 8b2334b79 删除无效内容2  
\# No commands remaining.

最后wq保存注释即可。  
4）.查看结果,执行git log ，你会发现只有一个commit记录了

2 分支合并，上面已介绍。

3 为什么要慎用Git rebase，什么情况出问题？？？

现在我们有这样的两个分支,test和master，提交如下：  
         D---E test  
         /  
A---B---C---F--- master  
在master执行git rebase test，然后得到如下结果：

D--------E ----    test  
         /                     
A---B---D---E---C‘---F’--- master

你在rebase后会更改分支历史，即原master分支是B-C-F（使用该分支的别的同事的本地分支就是如此），而现在实际远程分支是 B-D-E-C'-F', 同事的的本地分支版本的历史与远端版本不同，且没有很好的解决方案。  
详细见：[https://blog.csdn.net/gtlbtnq9mr3/article/details/80222523][https_blog.csdn.net_gtlbtnq9mr3_article_details_80222523]

对比 Git pull/merge/rebase  
git pull = git fetch + git merge FETCH\_HEAD  
git pull --rebase = git fetch + git rebase FETCH\_HEAD  
Git fetch做了什么？  
git fetch是将远程主机的最新内容拉到本地分支，但是拉下来的最新内容没有到工作区中，所以你看不到。  
git fetch 命令：  
$ git fetch <远程主机名> //这个命令将某个远程主机的更新全部取回本地  
如果只想取回特定分支的更新，可以指定分支名：  
$ git fetch <远程主机名> <分支名> //注意之间有空格  
最常见的命令如取回origin 主机的master 分支：  
$ git fetch origin master

git pull  
git fetch origin master //从远程主机的master分支拉取最新内容  
git merge FETCH\_HEAD //将拉取下来的最新内容合并到当前所在的分支中

[http_www.mamicode.com_info-detail-2428030.html]: http://www.mamicode.com/info-detail-2428030.html
[https_blog.csdn.net_tanga842428_article_details_53155860]: https://blog.csdn.net/tanga842428/article/details/53155860
[https_blog.csdn.net_aroundme_article_details_51223687]: https://blog.csdn.net/aroundme/article/details/51223687
[https_www.jianshu.com_p_dc367c8dca8e]: https://www.jianshu.com/p/dc367c8dca8e
[https_www.jianshu.com_p_48c9644e4bb6]: https://www.jianshu.com/p/48c9644e4bb6
[https_blog.csdn.net_j3t9z7h_article_details_85241850]: https://blog.csdn.net/j3t9z7h/article/details/85241850
[https_blog.csdn.net_gtlbtnq9mr3_article_details_80222523]: https://blog.csdn.net/gtlbtnq9mr3/article/details/80222523