Git原理+使用(超详细)
Git初识当我们写项目代码时，必要不断的更新版本，那么就必要一个东西去管理这些不同版本的文件—版本控制器。
现在最主流的版本控制器就是Git。它是一个可以记录工程的每一次改动和版本迭代的管理体系，同时方便多人协同作业。
！注意：Git只能跟踪文本文件的改动，好比第几行改了什么，但是图片，视频，二进制文件，并不能直观的观察到改了什么，好比只知道图片从100kb变为120kb。
安装Git
媒介(现在显示的ubuntu平台)
你可以通过输入git来看看有没有安装Git，如果安装了就会弹出以下界面。
https://i-blog.csdnimg.cn/direct/364f6c8a8bed469ca861340d35bc3215.png
安装Git
sudo apt-get install git -y 查看Git安装版本
https://i-blog.csdnimg.cn/direct/7d719ed20de147a7a1910c306652121a.png
Git基本操作
创建Git本地堆栈
因为堆栈是举行版本控制的文件目次，要想对文件举行版本控制，就必须先创建一个堆栈。
我们先创建一个gitcode目次，后续操作都在这个目次里面举行。
通过 git init命令创建一个本地堆栈
之后我们会发现有个.git的埋伏文件 ，注意不要修改这个目次的文件，它是用来跟踪管理堆栈的，我们可以输入tree .git命令进去看看
https://i-blog.csdnimg.cn/direct/2331be87d2dd4540b39bf0ba34024665.png
设置Git
安装完Git后最好先设置你的用户名称和e-mail地点。
git config [ --global ] user.name "Your Name" git config [ --global ] user.email "email@example.com" ------------------------------------------------------------------------ your name改为你的名字 email "email@example.com改为你的邮箱 --global是个可以选项，如果带上该选项表明这台呆板上的所有Git堆栈都会用这个设置，如果盼望不同堆栈有不同的名称和邮箱地点就不要带 。
可以通过一个命令来查看设置
root@hecs-95072:~/gitcode# git config -l
user.name=pikes
user.email=2994322314@qq.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
删除对应命令设置
git config [ --global ] --unset user.name git config [ --global ] --unset user.email 工作区，暂存区，版本库
[*]工作区：也就是电脑上要写的代码或文件的目次
[*]暂存区：一般存放在.git目次下的index文件中
[*]版本库：也叫堆栈，这个版本库中的所有文件都可以被Git管理起来，对于每个文件的修改，删除，Git都能跟踪。
在工作区写的代码和文件 必须通过git add命令，让暂存区的文件索引更新，再通过git commiit命令才能将文件添加到堆栈中举行管理~
添加文件
我们可以在包含.git的目次下创建一个文件，写入一些内容，使用git add命令将文件添加到暂存区
• 添加⼀个或多个⽂件到暂存区： git add [ file1 ] [ file2 ] ... • 添加指定⽬录到暂存区，包括⼦⽬录： git add [ dir ] • 添加当前⽬录下的所有⽂件改动到暂存区： git add . 使用 git commit命令将暂存区的内容添加到堆栈中
• 提交暂存区全部内容到本地堆栈中: git commit - m "message" • 提交暂存区的指定⽂件到堆栈区： git commit [ file1 ] [ file2 ] ... - m "message" 注意 -m选项是要形貌本次提交的message信息，以确保下次查看时知道本地提交的详细信息
通过 git log命令查看历史提交记录，因为我提交过频频，所以会出现一下信息
https://i-blog.csdnimg.cn/direct/9adbe93abb764db193a23eaecd305220.png
如果想看轻便的信息，可以加上一个参数
https://i-blog.csdnimg.cn/direct/8c6016a0f5a0494f8a232b3c6641b0f8.png
前面一大串黄色的字符串是每次提交的commit id。
查看.git目次
https://i-blog.csdnimg.cn/direct/e383f12167e94ec696aba433512a41d3.png
1:index就是我们的暂存区，add后的内容就添加在这里
2:HEAD就是我们默认指向master分支的指针
可以通过命令来查看
root@hecs-95072:~/gitcode# cat .git/HEAD
ref: refs/heads/master
root@hecs-95072:~/gitcode# cat .git/refs//heads/master
946c80e794901d4169040596e7d827647dc1e829
打引出来的字符串就是最新的commit id
3:objects是Git的对象库，里面包含了创建的各种版本库对象和内容，当执行git add命令时，暂存区目次更新，同时工作区被修改的文件内容被写入到对象库中一个新的对象中
我们可以看看object里面有什么
https://i-blog.csdnimg.cn/direct/06e446d19eb34758b18dea5cf3ef40b5.png
commit id分为两部分，前两位是文件夹名称，后38位是文件名称。因为文件是颠末安全哈希算法加密过的文件，我们要使用git cat-file命令来查看版本库对象的内容
https://i-blog.csdnimg.cn/direct/510eae429dbd4d579c9981549cbbba93.png
可以看到有一行tree c8d28685fa88d74a960702c1674b1559623b2c09。用同样的命令查看
https://i-blog.csdnimg.cn/direct/1814fd0a296e4383a24a2338a2b4678e.png
再继承看ReadMe中对应的
https://i-blog.csdnimg.cn/direct/f6db36e31c3b4c40b45b37d90a967d5d.png
如许就看到了我们刚刚做的修改。
修改文件
当我们对ReadMe文件举行修改后，堆栈中的ReadMe和工作区中的ReadMe是不同的，可以通过git status来查看距上次提交之后是否对文件举行修改。
https://i-blog.csdnimg.cn/direct/31680c90108d48ee9084d37c816939e5.png
它提示了，我们修改过了ReadMe但并没有添加和修改。
当我们好几个月前修改的代码，我们通过这个命令是看不到详细什么地方被修改的，所以我们就必要通过另一个命令来显示暂存区和工作区文件的差异git diff ,也可以通过git diff HEAD -- 命令查看版本库和工作区的文件区别
https://i-blog.csdnimg.cn/direct/61ec308f13b94513ac73e7340ebebc53.png
版本回退
因为我们提到过，Git能够管理文件的历史版本，这也是它的紧张作用之一。如果你因为工作出现题目，要在某个特定的历史版本重新开始，就必要版本回退功能了。
执行git reset命令用于回退版本，回退的本质是将版本库中的内容回退，工作区和暂存区是否回退由命令参数决定：
git reset [-- soft | -- mixed | -- hard ] [ HEAD ] --soft --mixed --hardHEAD将版本库回退到某个指定版本工作区，工作区暂存区不变 默认选项，将暂存区的内容回退指定版本内容，工作区不变 暂存区和工作区回退到指定版本代表指定回退的版本
• HEAD 分析： ◦ 可直接写成 commit id，表⽰指定退回的版本 ◦ HEAD 表⽰当前版本 ◦ HEAD^ 上⼀个版本 ◦ HEAD^^ 上上⼀个版本 ◦ 以此类推... • 可以使⽤ 〜数字表⽰： ◦ HEAD~0 表⽰当前版本 ◦ HEAD~1 上⼀个版本 ◦ HEAD^2 上上⼀个版本 ◦ 以此类推.. 版本回退原理
Git的版本回退速率非常快，因为Git内部有个指向当前分支的HEAD指针，就是refs/heads/master文件里保存的当前的master分支最新的commit id，当我们回退时候，master指针就会指向对应版本。
https://i-blog.csdnimg.cn/direct/b99bef60688542c884a570f558f4f4f7.png
https://i-blog.csdnimg.cn/direct/44221db647f14989b06b51d0360e624c.png
撤销修改
当我们在工作区写了很长时间代码后，但是老板不满足必要恢复到上一个版本怎么办，这时候分为三种情况：
1.工作区的代码，还没有add
root@hecs-95072:~/gitcode# vim ReadMe
root@hecs-95072:~/gitcode# cat ReadMe
大鹏一日同风起，扶摇直上九万里.
剑气纵横三万里，一剑光寒十九州.
皮克斯来了
测试撤销修改 //新增代码
可以使用git checkout -- 命令会到最近一次add或者commit时状态
https://i-blog.csdnimg.cn/direct/721ca395a32b4edaa1b42c8cecab27b7.png
2.已经add，但没有commit
我们可以使用git reset命令，带上--mixed参数，然后用git checkout -- 命令撤销在工作区的修改
3.已经add和commit
可以用git reset --hard HEAD^命令回退到上一个版本，但有个前提，就是还没有把自己本地版本库推送到远程。
删除文件
可以通过git rm 命令删除暂存区和工作区文件
root@hecs-95072:~/gitcode# touch test1 //创建文件
root@hecs-95072:~/gitcode# ls
ReadMetest1
root@hecs-95072:~/gitcode# git add test1//add到暂存区
root@hecs-95072:~/gitcode# git commit -m "add test1"//提交到版本库
add test1
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test1
root@hecs-95072:~/gitcode# git status
On branch master
nothing to commit, working tree clean
root@hecs-95072:~/gitcode# git rm test1。。删除暂存区和工作区的test1文件
rm 'test1'
root@hecs-95072:~/gitcode# git status//查看状态
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: test1
root@hecs-95072:~/gitcode# git commit -m "delete test1"//提交修改结果
delete test1
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 test1
root@hecs-95072:~/gitcode# git status
On branch master
nothing to commit, working tree clean
分支管理
分支管理是Git的最紧张的功能之一，就像两个平行宇宙，你正在学习Git，另一个平行宇宙的你在学习Redis，两者互不干扰，但在一个时间点重合，这时的你既学会了Git又学会了Redis。
刚刚版本回退的图里面已经知道，每次提交，Git都会把它们串成一条时间线，一个时间线就是一个分支，master分支就是主分支。
HEAD是指向master的master指向提交，所以HEAD指向的就是当前分支。
创建分支
可以通过git branch dev创建一个dev分支，用git branch命令查看当前本地所有分支
https://i-blog.csdnimg.cn/direct/775a8f3f514141008605afbb6487f7f7.png
*表现当前HEAD指向的分支是master分支，这时我们查看目次结构就可以看到新的分支
https://i-blog.csdnimg.cn/direct/1dcc94c8b1ec431e93038d028c832777.png
切换分支
我们可以切换到dev分支下举行开辟，使用git checkout命令
https://i-blog.csdnimg.cn/direct/57ee37ceddc64564ac126690e5087a65.png
这时HEAD就指向了dev分支上，下图便于理解：
https://i-blog.csdnimg.cn/direct/525b89ca12f34871abee9afbfaf8f972.png
我们可以在dev分支上举行操作并提交，再回到master分支上看看效果是不是一样
https://i-blog.csdnimg.cn/direct/3e85896d5871426d9b92020b6c03c80f.png
可以看到master分支上的内容并没有变革，可以看看dev和master分支指向，发现两者指向是不同的：
https://i-blog.csdnimg.cn/direct/9a53867243a644a693551c8d0a9127df.png
是因为我们在dev分支上提交的，切换到master分支后，master分支此刻的提交点并没有改变，HEAD此时指向的是master分支，如图所示：
https://i-blog.csdnimg.cn/direct/7927c9128474409692ad14e564e8f855.png
归并分支
我们要在master分支上看到新的提交，就必要将dev分支归并到master分支上：
https://i-blog.csdnimg.cn/direct/9beb7c9c23164e8dbd8a78099a28d3a8.png
git merge命令用于归并指定分支到当前分支，归并后，master就能看到dev分支提交的内容了
删除分支
https://i-blog.csdnimg.cn/direct/ad348e43672746f4b7cd42664952318c.png
归并辩论
当我们想归并分支时，并不是每次都会成功，好比下面这个例子：
root@hecs-95072:~/gitcode# cat ReadMe
大鹏一日同风起，扶摇直上九万里.
剑气纵横三万里，一剑光寒十九州.
皮克斯来了
测试dev分支
测试合并冲突aaa//修改代码
root@hecs-95072:~/gitcode# git add ReadMe
root@hecs-95072:~/gitcode# git commit -m "测试合并冲突"
测试合并冲突
1 file changed, 1 insertion(+), 1 deletion(-)
root@hecs-95072:~/gitcode# git checkout master
Switched to branch 'master'
root@hecs-95072:~/gitcode# cat ReadMe
大鹏一日同风起，扶摇直上九万里.
剑气纵横三万里，一剑光寒十九州.
皮克斯来了
测试dev分支
测试合并冲突111
root@hecs-95072:~/gitcode# vim ReadMe
root@hecs-95072:~/gitcode# cat ReadMe
大鹏一日同风起，扶摇直上九万里.
剑气纵横三万里，一剑光寒十九州.
皮克斯来了
测试dev分支
测试合并冲突bbb//此时master也进行修改
root@hecs-95072:~/gitcode# git merge dev
Updating d35e425..d1b0845
error: Your local changes to the following files would be overwritten by merge:
ReadMe
Please commit your changes or stash them before you merge.
Aborting
这时归并就会有辩论，如下图所示：
https://i-blog.csdnimg.cn/direct/569497897a4a40b7a7177ceffefbf139.png
这时就要手动调整辩论代码，并再次提交修正后的效果
https://i-blog.csdnimg.cn/direct/e507d30f685f43418dd21905d0e3df8c.png
这时辩论就解决完成，此时状态变为：
https://i-blog.csdnimg.cn/direct/50cf7413381b4bb48307fafa09ea52d4.png
分支管理策略
我们在归并分支时，如果顺利，Git会接纳Fast forward模式，删除分支后，查看分支历史，看不到分支信息，不知道最新提交的是归并进来的还是正常提交的。
但在归并辩论部分，我们会举行一次新的提交，这种不是Fast forward模式，如许的好处是，可以从分支历史看出分支信息，下图可以看到master是由其他分支归并得到的：
https://i-blog.csdnimg.cn/direct/c0c39e35e0d448eba86dc4534af936b6.png
其实Git支持我们不使用这个模式，那么就会在merge时生成一个新的commit，如许从分支历史上就可以看出分支信息。
起首创建分支test，切换到此分支，修改ReadMe文件，并提交一个新的commit
https://i-blog.csdnimg.cn/direct/1a73f49cd9384617951bd6077978411e.png
切回master分支，归并两个分支
https://i-blog.csdnimg.cn/direct/822a921ffd8e4331bf7b9ddfb82c1ed3.png
这里加上了 --no-ff参数，表现禁用Fast forward模式，因为禁用后会创建一个新的commit，所以要带上-m参数，写上本次形貌。
本次平常归并的状态为：
https://i-blog.csdnimg.cn/direct/6a81ec45c4a149d6b77dc50bd2a8ea36.png
分支策略
在平常开辟中，我们应该按照几个基本原则举行分支管理；
起首，master分支是非常稳固的，最好仅用来发布新版本，不能在上面干活，干活都在其他分支上，到时候将其他分支归并到master上，在master上发布新版本。
bug分支
加入我们在test分支上举行开辟，开辟到一半，发现master分支上有bug必要解决。在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，归并分支，然后将临时分支删除。
当我们test分支工作区的代码写了一半，还无法提交怎么办？Git提供了git stash命令，可以将当前工作区信息举行蕴藏，被蕴藏的内容可以在某个时刻恢复出来。
https://i-blog.csdnimg.cn/direct/0fefde83ee3c4a1d8902fb897cd91a6e.png
此时就可以看到，执行完git stash命令后，用git status查看工作区就是干净的，接下来就可以安心处理bug。
root@hecs-95072:~/gitcode# git checkout -b bug //创建bug分支
Switched to a new branch 'bug'
root@hecs-95072:~/gitcode# vim ReadMe
root@hecs-95072:~/gitcode# cat ReadMe
大鹏一日同风起，扶摇直上九万里.
剑气纵横三万里，一剑光寒十九州.
皮克斯来了
测试dev分支
测试归并辩论aaa
测试分支策略 假设修复完毕 //假设修复完毕
root@hecs-95072:~/gitcode# git add ReadMe //重新add和commit
root@hecs-95072:~/gitcode# git commit -m "修复bug"
修复bug
1 file changed, 1 insertion(+), 1 deletion(-)
root@hecs-95072:~/gitcode# git checkout master
Switched to branch 'master'
root@hecs-95072:~/gitcode# git merge --no-ff -m "merge bug branch" bug
Merge made by the 'ort' strategy.
ReadMe | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
root@hecs-95072:~/gitcode# cat ReadMe
大鹏一日同风起，扶摇直上九万里.
剑气纵横三万里，一剑光寒十九州.
皮克斯来了
测试dev分支
测试归并辩论aaa
测试分支策略 假设修复完毕
root@hecs-95072:~/gitcode# git branch -d bug //删除bug分支
Deleted branch bug (was 7bef88b).
此时，bug修复完毕，再回到test分支继承敲代码，可以看看刚刚的代码跑哪去了
https://i-blog.csdnimg.cn/direct/c01a7a0a53da4acb81765ae762ebf8cf.png
我们可以通过git stash pop或者git stash apply命令来恢复，紧张区别是前者恢复同时会把stash删了，后者不会。
https://i-blog.csdnimg.cn/direct/1d0ea6d979eb4df6829b89d3b0190343.png
但此时test分支并不能看见修复bug的代码，因为归并操作会辩论，我们最好在自己分支上归并master，再让master去归并自己分支，如许即便在解决辩论时出现错误，也不会影响master分支。(此处就不展示了)
删除临时分支
当我们必要添加实验性子代码时，为了不影响主代码，可以新建一个分支，称为feature分支，在上面开辟，归并，最后删除。
但如果写到一半，这个分支不要了，用传统的git branch -d 命令删除是不行的，必要用到 git branch -D命令
https://i-blog.csdnimg.cn/direct/71467cd5115b4c409baed1463fb8a030.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]