【闲谈】git
作者:互联网
怎么回事
某天下午,在拉取公司代码进行查看时,不小心自己在本地建了个dev分支,本着多一事不如少一事的原则,想把本地的分支删掉,但众所周知下午本就是迷迷糊糊的时间,点完delete后发现,公司git上的分支呢!吓得我赶紧和带我的老哥坦白,于是有了他对我如下的评价
就在我笑嘻嘻道歉的下一秒,部门老大冲进办公室就是一顿喊:谁tm干的
说来也是惭愧,在我两个月的开发经历中,只会clone、pull、push,之前在的公司是个小作坊,所有人的代码都往master上提交,而且事先分工明确,很少需要去手动合并代码,导致我到现在也是一问三不知
废话也不多说了,赶紧补一下git的基本知识
集中式vs分布式
集中式版本控制系统,版本库是集中存放在中央服务器的,这样就有个显而易见的问题:如果中央服务器挂了,大家今天都不用干活了(好耶)。但不干活肯定是不行的,毕竟要吃饭的嘛,所以现在用的git是分布式版本控制系统
所谓分布式就是根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,今天A哥电脑坏了,没关系,我从B哥那拷一份不就好了,这样就解决了集中式的弊端(当然了,这只是git的好处之一,其他让我们欲罢不能的优点放到后面再说)
git!
安装
(因为好多开发环境都是在Win上,这里就以Win为例)
在Windows上安装git很简单,只需去官网下载安装包一直下一步就好了。等安装结束后,随便找个地方右键就会发现出现Git GUI Here
和Git Bash Here
,前者代表了图形化界面,后者则是命令行
其实在很多工作环境中,做到这一步已经足够使用了,但最好还是完成以下的操作
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
创建版本库
所谓版本库就是仓库(repository),除了git的仓库还有我们熟知的maven仓库(跑题了)。其实版本库就是一个目录,只不过这个目录中所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”
创建版本库十分简单,尽管许多教程采用了命令行的方式进入目录并进行创建,但实际上都是动鼠标点点(至少我是这样的)。进入你想创建版本库的文件夹后,右键找到Git Bash Here
,打开以后就进入了git的命令行模式,输入git init
就可以在当前目录下创建版本库了。这里需要注意的是,当你创建完版本库后,当前目录下会多出一个.git的目录,这个是git用来追踪管理版本库的,有事没事千万别动它
不建议使用公司项目用来练习git!
把文件添加到版本库
将文件添加到版本库的前置条件是文件在版本库的目录下
然后就是
$ git add readme.txt
$ git commit -m "wrote a readme file"
前者是告诉git要将文件添加到仓库中,后者则是把文件提交到仓库。git commit
命令的-m
选项输入的是本次提交的内容,当然可以选择不输入,但git诞生的初衷就是对版本进行控制,为了团队间关系和睦,最好还是把信息加上,就像代码需要注释一样(笑)
千万不要用记事本去编辑git仓库下的任何文件,原因的话可以点击这里去参考,取而代之的,可以选择VScode或是notepad++
实时关注你的仓库状态
git status
可以让我们实时查看文件的修改状态,git diff
是查看difference的,可以观察到文件上次怎么被修改的
版本回退
耍过游戏机的小伙伴都知道一个刷装备的技巧,就是save-load大法,每次在刷装备前先save保存一下,刷出的装备如果不合心意,就直接load之前的存档。git当中也是一样的,每当你绝对文件修改到一定程度时,就可以为文件创建一个“快照”,也就是commit
,一旦文件乱了或是误删了,就可以直接从最近的一个commit
恢复
然而在实际的开发中,我们不可能精准的记住每次更新的内容都有哪些,git贴心的为我们提供了一个命令用来解决这个问题
git log
可以由最近到最远的提交记录,如果输出信息比较繁琐,可以通过--pretty=oneline
选项进行格式化输出
既然要回退,肯定要知道当前版本,也要知道回退到哪个版本。在git中,HEAD
表示当前版本,上一个版本则是HEAD^
,上上个版本则是HEAD^^
,这么一想,坏了,上一百个版本咋整,安啦,可以用HEAD~100
表示。所以回退到上一个版本的命令就是
$ git reset --hard HEAD^
在这个基础上还可以回退再上一个版本,但是先别着急,我们先用git log
查看版本库状态
回退之前
$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append B
e475afc93c209a690c39c13a46716e8fa000c366 add A
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
回退之后
e475afc93c209a690c39c13a46716e8fa000c366 (HEAD -> master) add A
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
会发现我们之前最新的那个版本已经看不见了!回退版本我们知道用什么命令,找回被回退的版本就要借助commit id
了,即那一串字符
$ git reset --hard 1094adb7b9b3807259d8cb349e7df1d4d6477073
版本号没必要写全,但是也有可能git无法根据你给的前缀找到唯一的版本号,那就出事了,所以还是建议复制粘贴一下
当然了,也可能出现你在回退后不小心把窗口关闭了,找不到版本号是多少。但git总是会留有后路的,可以通过git reflog
查询已经执行过的命令
工作区和暂存区
还记得在最一开始说的git add
和git commit
吗?因为博大精深的中文,“添加”和“提交”两个词似乎没什么区别,但是在git中这两个动作截然不同,现在就引入暂存区和工作区的概念来彻底立即什么是add什么是commit
其实说来也比较抽象,工作区是我们实际能看得见的文件目录,但是暂存区和分支更像是逻辑上的概念
工作区有隐藏目录.git
,它不算工作区,而是版本库,版本库里就有暂存区,以及git自动创建的分支master
,以及指向master
的指针HEAD
。可以简单的理解为“需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改”
当在版本库新建文件,且不对其进行add操作时,执行git status
,会发现这个新建的文件状态为Untracked
,代表这个文件并不受git的版本控制
管理修改
之前我们讨论的都是文件的修改,注意措辞,文件的修改,说明我们始终讨论的都是修改,而非文件,这也是在学习git时需要明确的概念:git管理的是修改,而非文件
这个结论可以通过一个小实验来证明
先对readme.txt做修改
然后添加并查看状态(Changes to be committed)
$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: readme.txt
#
再对readme.txt做修改
然后提交并查看状态(Changes not staged for commit)
$ git commit -m "git tracks changes"
[master 519219b] git tracks changes
1 file changed, 1 insertion(+)
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
会发现第二次修改并没有被提交(Changes not staged for commit)
我们来分析一下整个流程的思路:第一次修改 -> git add
-> 第二次修改 -> git commit
根据我们之前说的暂存区的概念,add
之后,第一次修改进入了暂存区准备提交,但是第二次修改过后直接commit
,在其修改的内容并没进暂存区的前提下进行了提交,提交的内容只有暂存区中的内容,所以第二次修改并不会被提交
所以结局方式是:第一次修改 -> git add
-> 第二次修改-> git add
-> git commit
结论:没有被add
的修改不会被commit
以上实验结果来自廖雪峰git专题中内容,我在本地测试的时候发现git不进行add也可以直接commit,版本为2.13.0.windows.1,目前还没有查到让我满意的解释方式,如果哪位老哥有知道的,可以给我留言,感谢!(跪了)
撤销修改
可以通过git check out -- <file>
对已有的修改进行撤销,但是分情况
- 文件自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态
- 文件已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态
总之就是让文件回到最近一次git add
或git commit
状态
除此之外,如果修改过的文件添加到暂存区,可以用命令git reset HEAD <file>
把暂存区的修改撤销掉,重新放回工作区,而工作区的修改直接用git check out -- <file>
进行撤销了
删除
如果是在公司的项目中,这块我觉得还是不学为妙,毕竟会的越多,删的越多(笑)
但还是简单了解一下
当你删除某个文件后,无非就是两种情况
- 确实需要删
git rm <file>
删除掉git commit <file>
- 删错了!
git checkout -- <file>
这个命令其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”
你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容
从来没有被添加到版本库就被删除的文件,是无法恢复的!
分支管理
从这一块开始,是我认为比较重要的部分了,毕竟正常公司并不会让所有人在开发阶段所有代码都往master上提交,都会有相应的dev、test分支
创建于合并分支
每次提交,git会把它们串成一条时间线,这条时间线就是一个分支。如果不去人为创建,默认只有一条分支,就是master
分支。严格来说,HEAD
并不指向提交,而是指向master
,master
才指向提交
当创建新的分支,比如dev
分支的时候,git就新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上
从现在开始,操作的分支就不再是master
而是dev
了
当在dev
上操作完成后,需要进行合并也很简单,就是让master
指向dev
甚至可以删除分支(血泪的教训),就是把dev
指针删除掉
$ git checkout -b dev
通过-b
选项可以在创建新的分支时切换到上面,checkout -b
等同于以下两个命令
$ git branch dev
$ git checkout dev
可以通过git branch
查看当前所在的分支,前面带星号的代表当前所在的分支
$ git branch
* dev
master
当一项工作进行完成,就可以将dev分支上的内容合并到master分支
$ git checkout master
$ git merge dev
这个命令的作用是将指定分支合并到当前分支
switch(建议使用)
在之前的操作中可以发现,切换分支命令git checkout <branch>
与撤销修改命令git checkout -- <file>
几乎一毛一样,为了能让二者的区别更加清晰,git推荐使用switch
命令进行分支的切换
创建和切换到dev分支可以像这样
$ git switch -c dev
切换到master分支可以这样
$ git switch master
解决冲突
现在创建新的分支并对readme.txt做修改并进行提交
$ git switch -c feature1
Switched to a new branch 'feature1'
修改文档最后一行为
Creating a new branch is quick AND simple.
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
然后切换回master分支也对文档的最后一行进行修改,最后进行提交
$ git switch master
Switched to branch 'master'
修改文档的最后一行为
Creating a new branch is quick & simple.
$ git add readme.txt
$ git commit -m "& simple"
[master 5dc6824] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
然后现在试着进行合并,因为我们现在的状态如图所示,git的“快速合并”可能就没那么好使了
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
果然,提示Automatic merge failed
,既然自动的合并不能成功进行,只能进行手动操作了,先看一下文档变成了什么样
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
git用<<<<<<<
和>>>>>>>
标记出了文档中冲突的位置,只需要根据实际情况对冲突的部分进行修改保留其一就可以了
再次提交
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
现在的情况就变成了这样
分支管理策略
如果直接使用git提供的fast forward
模式,在合并的时候会直接删除分支,这一点是不希望看到的。如果强制禁用fast forward
模式,git会在merge时生成一个新的commit
使用--no-ff
进行分支合并
$ git switch -c dev
Switched to a new branch 'dev'
$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+)
$ git switch master
Switched to branch 'master'
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
当不使用fast forward
模式时,merge后分支状态如下所示
在实际开发过程中,分支管理策略大概就像这样
- master分支应当是非常稳定的,其作用为发布新版本,一般不直接把代码提交上去
- dev分支是不稳定的,当需要发布新版本时,会将dev分支上的内容合并到master分支上
- 每个人都有自己的分支,时不时将代码提交到dev分支上就行
最后说一句
在实际开发过程中,因为大多是团队项目,代码发生冲突的概率有那么一些的大,所以每次在提交代码之前,最好先把代码拉取下来,确认没有发生冲突后再去提交,提交的时候看清楚提交到哪个分支上就好了
可能关于git还有些我没那么了解或者没遇到的问题,后期如果出现了也会在这篇博客更新
最后再再提醒一句
在公司的项目中,无论是什么,只要涉及到delete的操作一定要万分小心,不管是不是在测试环境或者开发环境
本文内容参考
git教程
标签:git,dev,add,master,版本,commit,闲谈 来源: https://www.cnblogs.com/colee51666/p/16443942.html