Git初识
当我们写项目代码时，必要不断的更新版本，那么就必要一个东西去管理这些不同版本的文件—版本控制器。
现在最主流的版本控制器就是Git。它是一个可以记录工程的每一次改动和版本迭代的管理体系，同时方便多人协同作业。
！注意：Git只能跟踪文本文件的改动，好比第几行改了什么，但是图片，视频，二进制文件，并不能直观的观察到改了什么，好比只知道图片从100kb变为120kb。
安装Git
媒介(现在显示的ubuntu平台)
你可以通过输入git来看看有没有安装Git，如果安装了就会弹出以下界面。
安装Git
sudo apt-get install git -y 查看Git安装版本
Git基本操作
创建Git本地堆栈
因为堆栈是举行版本控制的文件目次，要想对文件举行版本控制，就必须先创建一个堆栈。
我们先创建一个gitcode目次，后续操作都在这个目次里面举行。
通过 git init命令创建一个本地堆栈
之后我们会发现有个.git的埋伏文件 ，注意不要修改这个目次的文件，它是用来跟踪管理堆栈的，我们可以输入tree .git命令进去看看
设置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命令查看历史提交记录，因为我提交过频频，所以会出现一下信息
如果想看轻便的信息，可以加上一个参数
前面一大串黄色的字符串是每次提交的commit id。
查看.git目次
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 bjects是Git的对象库，里面包含了创建的各种版本库对象和内容，当执行git add命令时，暂存区目次更新，同时工作区被修改的文件内容被写入到对象库中一个新的对象中
我们可以看看object里面有什么
commit id分为两部分，前两位是文件夹名称，后38位是文件名称。因为文件是颠末安全哈希算法加密过的文件，我们要使用git cat-file命令来查看版本库对象的内容
可以看到有一行tree c8d28685fa88d74a960702c1674b1559623b2c09。用同样的命令查看
再继承看ReadMe中对应的
如许就看到了我们刚刚做的修改。
修改文件
当我们对ReadMe文件举行修改后，堆栈中的ReadMe和工作区中的ReadMe是不同的，可以通过git status来查看距上次提交之后是否对文件举行修改。
它提示了，我们修改过了ReadMe但并没有添加和修改。
当我们好几个月前修改的代码，我们通过这个命令是看不到详细什么地方被修改的，所以我们就必要通过另一个命令来显示暂存区和工作区文件的差异git diff [file],也可以通过git diff HEAD -- [file]命令查看版本库和工作区的文件区别
版本回退
因为我们提到过，Git能够管理文件的历史版本，这也是它的紧张作用之一。如果你因为工作出现题目，要在某个特定的历史版本重新开始，就必要版本回退功能了。
执行git reset命令用于回退版本，回退的本质是将版本库中的内容回退，工作区和暂存区是否回退由命令参数决定：
git reset [-- soft | -- mixed | -- hard ] [ HEAD ] | --soft | --mixed | --hard | HEAD | | 将版本库回退到某个指定版本工作区，工作区暂存区不变 | 默认选项，将暂存区的内容回退指定版本内容，工作区不变 | 暂存区和工作区回退到指定版本 | 代表指定回退的版本 |
• HEAD 分析： ◦ 可直接写成 commit id，表⽰指定退回的版本 ◦ HEAD 表⽰当前版本 ◦ HEAD^ 上⼀个版本 ◦ HEAD^^ 上上⼀个版本 ◦ 以此类推... • 可以使⽤ 〜数字表⽰： ◦ HEAD~0 表⽰当前版本 ◦ HEAD~1 上⼀个版本 ◦ HEAD^2 上上⼀个版本 ◦ 以此类推.. 版本回退原理
Git的版本回退速率非常快，因为Git内部有个指向当前分支的HEAD指针，就是refs/heads/master文件里保存的当前的master分支最新的commit id，当我们回退时候，master指针就会指向对应版本。
撤销修改
当我们在工作区写了很长时间代码后，但是老板不满足必要恢复到上一个版本怎么办，这时候分为三种情况：
1.工作区的代码，还没有add
- root@hecs-95072:~/gitcode# vim ReadMe
- root@hecs-95072:~/gitcode# cat ReadMe
- 大鹏一日同风起，扶摇直上九万里.
- 剑气纵横三万里，一剑光寒十九州.
- 皮克斯来了
- 测试撤销修改 //新增代码
2.已经add，但没有commit
我们可以使用git reset命令，带上--mixed参数，然后用git checkout -- [file]命令撤销在工作区的修改
3.已经add和commit
可以用git reset --hard HEAD^命令回退到上一个版本，但有个前提，就是还没有把自己本地版本库推送到远程。
删除文件
可以通过git rm [file]命令删除暂存区和工作区文件
- root@hecs-95072:~/gitcode# touch test1 //创建文件
- root@hecs-95072:~/gitcode# ls
- ReadMe test1
- root@hecs-95072:~/gitcode# git add test1 //add到暂存区
- root@hecs-95072:~/gitcode# git commit -m "add test1" //提交到版本库
- [master 7b8ebfd] 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" //提交修改结果
- [master 729581a] 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命令查看当前本地所有分支
*表现当前HEAD指向的分支是master分支，这时我们查看目次结构就可以看到新的分支
切换分支
我们可以切换到dev分支下举行开辟，使用git checkout命令
这时HEAD就指向了dev分支上，下图便于理解：
我们可以在dev分支上举行操作并提交，再回到master分支上看看效果是不是一样
可以看到master分支上的内容并没有变革，可以看看dev和master分支指向，发现两者指向是不同的：
是因为我们在dev分支上提交的，切换到master分支后，master分支此刻的提交点并没有改变，HEAD此时指向的是master分支，如图所示：
归并分支
我们要在master分支上看到新的提交，就必要将dev分支归并到master分支上：
git merge命令用于归并指定分支到当前分支，归并后，master就能看到dev分支提交的内容了
删除分支
归并辩论
当我们想归并分支时，并不是每次都会成功，好比下面这个例子：
- root@hecs-95072:~/gitcode# cat ReadMe
- 大鹏一日同风起，扶摇直上九万里.
- 剑气纵横三万里，一剑光寒十九州.
- 皮克斯来了
- 测试dev分支
- 测试合并冲突aaa //修改代码
- root@hecs-95072:~/gitcode# git add ReadMe
- root@hecs-95072:~/gitcode# git commit -m "测试合并冲突"
- [dev d1b0845] 测试合并冲突
- 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
这时就要手动调整辩论代码，并再次提交修正后的效果
这时辩论就解决完成，此时状态变为：
分支管理策略
我们在归并分支时，如果顺利，Git会接纳Fast forward模式，删除分支后，查看分支历史，看不到分支信息，不知道最新提交的是归并进来的还是正常提交的。
但在归并辩论部分，我们会举行一次新的提交，这种不是Fast forward模式，如许的好处是，可以从分支历史看出分支信息，下图可以看到master是由其他分支归并得到的：
其实Git支持我们不使用这个模式，那么就会在merge时生成一个新的commit，如许从分支历史上就可以看出分支信息。
起首创建分支test，切换到此分支，修改ReadMe文件，并提交一个新的commit
切回master分支，归并两个分支
这里加上了 --no-ff参数，表现禁用Fast forward模式，因为禁用后会创建一个新的commit，所以要带上-m参数，写上本次形貌。
本次平常归并的状态为：
分支策略
在平常开辟中，我们应该按照几个基本原则举行分支管理；
起首，master分支是非常稳固的，最好仅用来发布新版本，不能在上面干活，干活都在其他分支上，到时候将其他分支归并到master上，在master上发布新版本。
bug分支
加入我们在test分支上举行开辟，开辟到一半，发现master分支上有bug必要解决。在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，归并分支，然后将临时分支删除。
当我们test分支工作区的代码写了一半，还无法提交怎么办？Git提供了git stash命令，可以将当前工作区信息举行蕴藏，被蕴藏的内容可以在某个时刻恢复出来。
此时就可以看到，执行完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 7bef88b] 修复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分支继承敲代码，可以看看刚刚的代码跑哪去了
我们可以通过git stash pop或者git stash apply命令来恢复，紧张区别是前者恢复同时会把stash删了，后者不会。
但此时test分支并不能看见修复bug的代码，因为归并操作会辩论，我们最好在自己分支上归并master，再让master去归并自己分支，如许即便在解决辩论时出现错误，也不会影响master分支。(此处就不展示了)
删除临时分支
当我们必要添加实验性子代码时，为了不影响主代码，可以新建一个分支，称为feature分支，在上面开辟，归并，最后删除。
但如果写到一半，这个分支不要了，用传统的git branch -d 命令删除是不行的，必要用到 git branch -D命令
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
