git小指引

git是一名开发工程师的必备技能之一。这可以说是入门或指引式的，后期会继续完善和补充。

git是一个分布式的版本控制系统，两个关键字，分布式和版本。首先说说什么是版本，打个简单点的例子。比如一个文件F，A作者开始写，变成了F’， 然后B又在文件F上修改，变成了F”。可以简单地理解F’和F”是两个版本。至于分布式？我的理解是，A作者修改文件F变成了F’ F” F”…. 而B作者修改文件F变成了F1 F2 F3… 两个作者的修改可以独立进行 互不影响。

A作者修改的文件的地方，称之为工作区。改完以后会把这个修改结果保存到一个地方叫暂存区，暂存区的东西感觉可以了，就把这个作为一个版本比如F’ 保存起来。

下面将以下工作流：

A作者想要把一个文件夹下面的东西通过版本管理工具管理起来：
git init

然后对文件F进行了修改，通过运行命令git add . 把修改结果保存到暂存区；通过git commit -m “ 保存修改F’ ”把修改结果提交为一个版本F’。

提交的时候想改以下作者的信息等信息，可以通过git config –global的命令进行配置这些信息。这些信息最终是保存到用户目录的一个.git之类的文件当中。

提交的时候想给这个版本加点说明是通过git commit -m ‘版本说明’的方式进行的。

提交完以后想要看一下提交的记录：git log…

发现提交的东西写错了，重新改一下：git reset –hard [某个版本]

有些东西不想用版本管理： 创建一个.gitignore文件 把不要管理的文件路径放进去

想查看上一次提交和这次提交的区别：git diff

这个时候A作者想着让B作者帮忙改这个文件F，但是A作者不想自己的东西被影响： git checkout [branchA] 创建一个分支B，让作者B的改动的版本都放在分支B里面。

分支是什么？你可以想象一棵树，树根都是文件A，但是可以生成多个树枝，每个树枝都可以长的不一样。每个树枝都有一个叶子，作者A可以继续在这个叶子后面的树枝上长不同的叶子。。

ok…

已经比喻不下去了…

git理解起来说复杂，其实也简单。本质上，每一次提交都会生成一个文件，这个文件包含的你的修改内容的信息和提交的作者的信息。比如是作者A在某年某月修改了第20行和第30行的第几个字等等。然后每次改一次都生成一个提交记录文件。在计算机内存中，是始终有一个所谓的HEAD指针指向这个提交记录的。

版本管理必然是要操作各个版本的，比如恢复某个版本等等，就是将HEAD指针指向那个要恢复的版本，具体底层是怎么实现的呢？我们可以不关系。就是HEAD指针移到那个那位置（git reset –hard [提交版本号]），然后本地的（工作区）文件就变成了那个版本的状态了。

还有什么git rebase。。什么命令什么的？这个命令相当于是说要把作者B改的东西（提交版本）应用在作者A的文件上。

两人修改文件必然会产生冲突，冲突的解决，git无法自动完成，因为它不知道你具体要改成的结果是什么。这个只要你自己把需要的留下把不要的删除就是了。
一般会有

》》》》》HEAD
作者A改的东西

作者B的东西
《《《《 版本2

改成比如：

作者B的东西

就行了。

至于其他命令：
git checkout -b feature/branchA 切换到feature/branchA分支
git reset –hard [123124] 回到123124版本
git checkout [相对于工作区的文件路径] 将暂存区的修改恢复

至于云端的版本。其实本质上和本地的作者A的分支和作者B的分支没啥区别。当你git push master origin/master的时候，其实是把你本地的master分支各个修改版本应用到远程origin/master分支上。

如果疏漏，欢迎指正。