标签：git dev add master 版本 commit 闲谈
怎么回事
某天下午，在拉取公司代码进行查看时，不小心自己在本地建了个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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。