git项目分支管理

Ubuntu下安装与卸载git

查看是否已经安装：git --version
卸载git：sudo apt-get remove git -y
安装git：sudo apt install git -y
-y表示yes

本地仓库

仓库是进行版本控制的⼀个文件目录。我们要想对文件进行版本控制，就必须先创建一个仓库出来。
创建本地仓库：git init在当前目录下创建本地仓库

然后就可以得到一个名为.git的隐藏文件。里面的内容是用来追踪和管理仓库的。

配置本地仓库

当安装Git后首先要做的事情是设置你的用户名称和e-mail地址，这是非常重要的。配置命令为：

git config --global user.name "Your Name"   
git config --global user.email "email@example.com"  
# 把Your Name 改成你的昵称
# 把email@example.com 改成邮箱的格式，只要格式正确即可。

其中--global 是一个可选项。如果使用了该选项，表示这台机器上所有的Git仓库都会使用这个配置。如果你希望在不同仓库中使⽤不同的name 或email ，可以不要。注意的是，执行命令时必须要在仓库里。

查看当前仓库配置：git config -l

删除对应的配置命令为：

git config --global --unset user.name
git config --global --unset user.email

关于仓库的管理

当我们配置好我们的仓库时，此时在git下创建一个文件

当前情况下并不能进行对temp文件的管理。因为当前目录其实不能算是本地仓库。真正的本地仓库其实就是隐藏目录.git。仓库又名版本库。但是也不能放到.git目录中。所以我们创建的gitcode就是我们放我们自己文件的地方，这个目录叫工作区。

temp文件就在下图中的工作区。
图中的stage叫暂存区。英⽂叫stage或index。一般存放在.git 目录下的index文件（.git/index）中，我们把暂存区有时也叫作索引（index）。

上图还存在一个Head指针指向master分支。
当对工作区修改（或新增）的文件后，可以使用git add 命令时，将工作区的文件添加到暂存区。
当执⾏提交操作git commit 时，master分支会做相应的更新，可以简单理解为暂存区的内容才会被真正写到版本库中。
在版本库中还存在一个库，叫做objects（对象库）。里面存储了很多的git对象。修改的工作区内容会写入对象库的一个新的git对象中。每add一次就会存一次修改的内容，所以对象库中存了很多的对象，将这些对象维护起来就是维护了文件的所有的版本，这就完成了版本的管理。
其实暂存区就是对象库中每个对象的索引。 master同样也是存的对象的索引。

上图.git就是版本库，HEAD就是HEAD指针，指向master。object就是存的一个个的对象。因为还没有对仓库进行add操作，所以还没有index。

添加与查看文件

添加⼀个或多个文件到暂存区：git add [file1] [file2] ...

添加指定目录到暂存区，包括子目录：git add [dir]
添加当前目录下的所有文件改动到暂存区：git add .

再使用git commit命令将暂存区内容添加到本地仓库中：
提交暂存区全部内容到本地仓库中:git commit -m "message"
提交暂存区的指定文件到仓库：git commit [file1] [file2] ... -m "message"
注意git commit 后面的 -m选项，要跟上描述本次提交的message，由用户自己完成，这部分内
容绝对不能省略，并要好好描述，是用来记录提交细节，是给我们人看的。

git commit 命令执行成功后会告诉我们，1个文件被改动（就是我们新添加的temp⽂件），插入了一行内容（temp有一行内容）。

我们还可以多次add不同的⽂件，而只commit⼀次便可以提交所有⽂件，是因为需要提交的文件是通通被add到暂存区中，然后一次性commit暂存区的所有修改。如：

我们可以使用git log命令来查看历史提交记录
该命令显示从最近到最远的提交日志，并且可以看到我们 commit 时的日志消息。
也可以使用git log --pretty=oneline来精简的打印一行信息。

需要说明的是，我们看到的一大串类似ca7fcd0ed82845128a0e741baaeaa057de668161 的是每次提交的commit id(版本号)，每次提交都会有这个id，可以定位到我们每次的提交记录。用十六进制表示。

查看.git文件

当我们使用了上面命令添加文件后，可以发现确实出现了index

index 就是我们的暂存区，add后的内容都是添加到这里的。
HEAD 就是我们的默认指向master分支的指针：

master其实就是目录下的某个分支的一个文件。

可以查看master的内容：

存储的就是最近一次commit id，这个id其实是一个索引，对应的是对象库中的一个对象。

object是Git的对象库，里面包含了创建的各种版本库对象及内容。当执行git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的⼀个新的对象中，就位于".git/objects"⽬录下

查找 object 时要将commit id 分成2部分，其前2位是文件夹名称，后38位是文件名称。
我们可以使用git cat-file -[id] 命令来查看版本库对象的内容：
git cat-file -p -[id]就是打印精简的内容

查看文件对应的内容可以得到我们提交时的描述（massage），还有parent，即我们上一次提交时的commit id，还有tree 后面的一个id。我们可以看一下得到：

再看一下temp对应的id值得到的就是我们刚刚修改的内容，注意是修改，不是全部。
上述得到的所有的id都可以在objects目录下找到。

综上，master存的id值得到的是最近一次的修改massage和各种信息，信息中存在tree后面的值，查看得到我们添加的文件和对应的id值，再查看id值就得到了我们添加的内容了。

修改文件

之前总是说git在管理文件，其实并不。
Git 比其他版本控制系统设计得优秀，因为 Git 跟踪并管理的是修改，而非文件。
查看仓库状态：
git status：当我们修改了工作区中的一个文件时，可以使用这个命令查看工作区的状态

上图就是修改了temp，可以使用git status，可以看到提示修改的文件没有提交到暂存区。还有我们修改的文件时temp。
但是此时我们并不知道我们修改了哪些内容。
可以使用git diff [file]命令查看修改的内容

git diff [file] 命令用来显示暂存区和工作区文件的差异，显示的格式正是Unix通用的diff格式。
第一行表示：a表示改之前的文件吗，b表示改之后的
第三行和第四行也是改之前和改之后
第五行是下面显示的内容的描述， -1 表示显示的是改之前第一行内容 +1和2表示改动后第一行开始连续两行内容。

也可以使用 git diff HEAD -- [file] 命令来查看版本库和工作区文件的区别。
然后再git add后再使用git status看仓库状态

提示需要提交到本地仓库，需要commit。然后显示暂存区中修改了哪些文件。

上图就是我们再次commit后，再次查看status显示没有什么可修改的。

版本回退

Git 能够管理文件的历史版本，这也是版本控制器重要的能力。如果有⼀天你发现之前的工作做的出现了很大的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。

执行 git reset 命令用于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是
要将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定：
git reset 命令语法格式为： git reset [--soft | --mixed | --hard] [HEAD]

• --mixed 为默认选项，使用时可以不带参数就默认这个参数。该参数将暂存区的内容退回为指定提交版本内容，工作区文件保持不变。
• --soft 参数对于工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
• --hard 参数将暂存区，版本库和工作区都退回到指定版本。切记工作区有未提交的代码时不要用这个命令，因为工作区会回滚，你没有提交的代码就再也找不回了，所以使用该参数前⼀定要慎重。
  HEAD 说明：

◦ 可直接写成 commit id，表示指定退回的版本
◦ HEAD 表示当前版本
◦ HEAD^ 上⼀个版本
◦ HEAD^^ 上上⼀个版本
◦ 以此类推…
• 可以使用 〜数字表示：
◦ HEAD~0 表示当前版本
◦ HEAD~1 上⼀个版本
◦ HEAD^2 上上⼀个版本
◦ 以此类推…

可以发现，当我们使用第一次提交的id值进行回退时，工作区的其他文件也没有了。
当我们后悔这个操作，想回到原来的版本时，可以使用上一个版本的id值进行回退。运气好能找到这个id值就可以回退回去，找不到那就无法回退了。

可以发现此时已经回到我们回退前的样子了。

如果真的找不到之前的id值，Git 还提供了⼀个 git reflog 命令能补救⼀下，该命令用来记录本地的每⼀次命令。

使用 git reflog 命令可以查到之前的命令操作，可以看到有前缀id值，使用这个id值也是可以回退到这个版本的。但是我们总是会进行很多次git操作，使用多了，可能就得不到之前的id值了。

值得说的是，Git的版本回退速度非常快，因为Git在内部有个指向当前分支（此处是master）的HEAD指针， refs/heads/master路径文件里保存当前master 分支的最新 commit id 。当我们在回退版本的时候，Git仅仅是给refs/heads/master 中存储一个特定的version，可以简单理解成如下示意图：

撤销修改

如果我们在我们的工作区写了很长时间代码，越写越写不下去，觉得自己写的实在是垃圾，想恢复到
上一个版本。

总共三种情况，一是撤销工作区的修改，二是撤销暂存区的修改，三是撤销版本库的修改。

情况一：对于工作区的代码，还没有 add

第一种方式就是直接删除写的代码，但是在这样并不好，容易出错。
第二种就是使用git提供的方式，使用git checkout -- [file] 命令让工作区的文件回到最近一次add或者commit的状态。要注意git checkout -- [file] 命令中的 -- 很重要，一旦省略该命令就是其他意思了。

可以发现新添加的new word 已经没有了。

情况二：工作区和暂存区都已经修改，还没有 commit

方法一：可以使用前面说的git reset命令，可以跟hard，直接工作区，暂存区，版本库，三个地方全部回退。
方法二：可以使用git reset命令，使用默认的 --mixed，只回退暂存区，然后就是情况一，在使用情况一的方法即可。后面跟HEAD即可，HEAD标识commit的当前版本。

情况三：三个区都已经修改了

这种情况如果要回退的话，前提条件是还没有push到远端仓库，否则不能真正意义上的说是回退。
直接使用git reset命令加 --hard即可。因为HEAD标识当前版本，所以要使用HEAD^表示上一个版本。

删除文件

如何删除版本库中的文件？
当我们删除一个工作区的文件时，即rm 一个文件，此时在工作区删除了这个文件，但是本地仓库中并没有删除。

此时我们删除了file3，说明修改了file3，于是就git add file3，此时add的就是file3的修改。此时再git status查看工作区的状态，显示就是删除了file3，然后commit一下。

上述使用了三步进行删除，我们还可以使用git rm [file]进行删除操作。

创建分支

在刚创建仓库的时候，本地存在的分支就只有master分支，通过git branch命令查看：

在版本回退里，已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是一
个分支。截至到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。
还需要再理解一下HEAD，HEAD严格来说指向的是当前工作的分支。可以发现master前面带*，就是我们正在master上工作的意思，而master指向最近的一次提交。

创建一个分支：
使用git branch [name]命令

此时HEAD仍然指向master

此时在git目录下也存在了一个dev分支：

打印看一下master和dev的内容

发现是一样的 。

因为创建分支时是在最新的版本上创建的分支，所以和master指向的都是最新的提交。

注：在某个分支下的add和commit，就是这个分支下的版本。

切换分支

我们此时创建一个分支，此时要做的就是到这个分支下面，需要做的就是让HEAD指向该分支。
此时使用git checkout [name]来切换分支。

此时在新的分支下修改temp，发现并没有被修改。切回dev分支下后发现有了修改的内容。

此时就是上图的情况，可以使用git cat-file -p -[id]看一下dev下的信息，可以看到父亲的id就是master的id，即一次提交的id。

合并分支

为了在master主分支上能看到新的提交，就需要将 dev分支合并到 master 分支。
合并分支前需要先切换到master分支，然后使用git merge [name]命令进行分支的合并。

可以发现此时master指向的就是dev指向的值了，即最新的提交。
可以看到上面合并后先显示的是Fast-forward，即快速模式，合并速度很快。即直接指向了最新的一次提交就算是合并了，但也不是每次都是快进模式的。

删除分支

合并完成后,dev分支对于我们来说就没用了，那么dev分支就可以被删除掉，注意如果当前正处于某分支下，就不能删除当前分支。删除分支的命令是git branch -d [name]

此时分支如上图，这里的创建分支然后合并其实就是不改变master，然后在新的一个分支修改，修改好了以后，确定下来然后master指向他。因为创建、合并和删除分支非常快，所以Git鼓励使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是⼀样的，但过程更安全。

强制删除分支：
当我们还没有提交的时候，如果要删除一个分支，使用git branch -d [name]是不行的。在没有提交的时候要删除一个分支要使用强制删除分支，此时应该使用git branch -D [name]，d改为大写的D。

合并冲突

上面的合并是master没有修改的时候合并的，当master分支修改的时候，合并的时候该怎么合并呢？此时分支之间就会产生冲突。
使用git checkout -b [name]命令创建一个新的分支并切换

此时进行合并的话就会显示合并冲突

此时提示我们解决掉冲突后再提交，我们可以看一下temp中的内容

发现ReadMe文件有冲突后，可以直接查看文件内容Git会⽤<<<<<<<，=======，>>>>>>>来标记出不同分支的冲突内容。
此时直接打开文件将冲突的删掉，留下我们需要的即可。即对当前的temp做修改，修改后再进行add和commit。或者直接提交也行，就把当前没有做修改的认为是我们需要的。因为此时冲突后的temp就认为是合并后的文件了。
此时的版本状态如下：

dev还是指向他的分支，master指向合并后的版本。
我们也可以通过命令来查看类似图片一样的分支图形git log --graph --abbrev-commit

ff与no-ff

通常合并分支时，如果可能，Git会采用 Fast forward 模式，即ff。

在这种 Fast forward 模式下，删除分支后，查看分⽀历史时，会丢掉分支信息，看不出来最新提交的是merge进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：

那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev 分支，但依旧能看到master，其实是由其他分支合并得到（即第一行显示的merge信息）：

Git支持我们强制禁用 Fast forward 模式，那么就会在merge时生成一个新的 commit ，这样，从分支历史上就可以看出分支信息。

--no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit ，所以加上 -m 参数，把描述写进去。

使用方法为git merge --no-ff -m "描述信息" 分支名

不使用 Fast forward 模式，merge后就像这样：

git分支策略

实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活。干活干活都在dev分支上，也就是说，dev分支是不稳定的。每个人都有自己的分支，写好以后合并到dev上面，dev分支测试后合并到master上才能发布。

bug分支

假设我们在dev分支上面进行开发，开发到一半，突然发现master分支上面存在bug，此时解决这个bug该怎么办呢？

在git版本管理中，每个bug都可以通过一个新的临时分支来修复，修复后再合并分支，然后将临时分支删除。
假设现在dev分支下的代码开发了一半，但是还没有提交怎么办？
此时如果直接创建新的分支， 那么dev分支下修改的代码也会出现在新的分支下面。因为dev分支还没有提交，提交了就不会出现这种情况，提交后就是这个分支下的版本了，在其他分支下不显示。
所以git提供了一个git stash命令，可以将当前工作区信息进行储藏，被储藏的内容可以在将来某个时刻恢复出来。但是只能储藏被git管理的文件，没有被管理的是无法储藏的

储藏 dev工作区之后，由于我们要基于master分支修复bug，所以需要切回 master 分支，再新建临时分支来修复bug。此时再新建的分支就不存在刚刚已经修改的内容了，而是没有修改过的，上线的master分支的内容，我们此时再修改bug，就不会受dev下修改内容的影响了。

我们就在文本中添加abcde来表示修改bug。
修复完成后，记得add然后commit，然后切换到 master 分支，并完成合并，最后删除 fix_bug 分支。

至此，bug修复完毕，切回dev分支下接着开发新功能。
刚刚使用git stash命令相当于将修改存储在了stash里，可以使用git stash list查看stash中存储了什么

使用git stash pop命令恢复原来储藏的修改。恢复的同时，会将stash删除掉。

另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，需要用 git stash drop 来删除；可以多次stash，恢复的时候，先用 git stash list 查看，然后恢复指定的stash，用命令git stash apply stash@{0} ，stash像是一个栈，后进先出。

此时版本情况如下：

此时如果直接master和dev合并，可能导致master出错，所以此时要在dev下合并，dev合并master。修改好以后，然后再让master合并dev。这样做的目的是有冲突可以在本地分支解决并进行测试。

在dev下对合并冲突做了修改以后，就可以直接在master下合并dev了，因为dev是合并的master，包含了master，dev此时就相当于在master下做了修改，不存在合并冲突的情况。

远程操作

上面演示的都是本地仓库，在本地的一个仓库进行的版本管理，但是git其实是一个分布式版本控制系统。
可以简单理解为，我们每个人的电脑上都是⼀个完整的版本库，这样你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（比如运气差，硬盘坏了，上面的所有东西全部丢失，包括git的所有内容）
我们完全可以自己搭建一台运行Git的服务器，不过没必要，这完全是小题大作，这个世界上存在GitHub，gitee，等一些代码托管平台。只需要使用这些平台，我们就可以有一个中央服务器了，每个开发人员都在这样的平台拉取和推送代码。
我们使用gitee来演示：
#从创建好的远程仓库中我们便能看到，之前在本地学习过的分支，也存在于远程仓库中并被管理起来了。刚创建的仓库有且只有一个默认的master分支。

克隆仓库

我们在本地克隆一个仓库需要得到仓库的地址才可以，这个仓库的地址仓库中都会表明。

SSH协议和HTTPS协议是Git最常使用的两种数据传输协议。SSH协议使用了公钥加密和公钥登陆机制，体现了其实用性和安全性，使用此协议需要将我们的公钥放上服务器，由Git服务器进行管理。使用HTTPS方式时，没有要求，可以直接克隆下来。
https协议克隆：
克隆仓库使用git clone命令。

注意不能在本地仓库中执行git clone命令。
此时克隆下来的远程仓库和上面讲本地仓库的结构是完全一样的。
使用git remote可以查看远程仓库的名字，发现叫origin，默认叫这个名字，使用git remote -v可以看更详细的远端信息。打印出来的两个远端地址，fetch代表拉取，push代表推送，存在这两个表示我们有这两个权限。

ssh协议克隆：
我们直接将ssh的链接拷贝下来进行克隆试一下：

显示权限不够，没有公钥。
ssh协议需要公钥，
第一步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa（私钥，不能公开） 和 id_rsa.pub（公钥） 这两个文件，如果已经有了，可直接跳到下一步。如果没有，需要创建SSH Key：

目录下什么都没有，所以需要先创建，使用ssh-keygen -t rsa -C "邮箱"命令创建公钥。邮箱必须和远程仓库的邮箱一致。
创建邮箱时一路回车创建即可

创建完成以后可以在用户主目录里找到.ssh，.ssh中还能找到id_rsa 和 id_rsa.pub 两个文件，这两个就是SSH Key的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放心地告诉任何人。

第二步：添加自己的公钥到远端仓库。

将公钥添加进去即可，添加后需要输入密码验证。

此时就添加成功了，可以进行仓库的克隆了。如果有多个人协作开发，GitHub/Gitee允许添加多个公钥，只要把每个人的电脑上的Key都添加到GitHub/Gitee，就可以在每台电脑上往GitHub/Gitee上提交推送了。

推送

当我们克隆一个仓库以后，就相当于存在了一个本地仓库，我们本地仓库修改后然后推送到远程仓库。当我们对本地仓库master进行了一次提交，此时远程是不知道本地的情况的，需要将本地的master分支推送到远程才行，注意此时推送的是本地的master分支，此时是分支与分支之间的交互。

注意:如果要进行推送，必须本地的要与远程的邮箱和用户一致

当我们在远程克隆下来的仓库中查看仓库状态的时候，还会提示建议我们push。
到这里我们已经将内容提交至本地仓库中，如何将本地仓库的内容推送至远程仓库呢，需要使用 git
push 命令，该命令用于将本地的分支版本上传到远程并合并，命令格式如下：

git push <远程主机名> <本地分支名>:<远程分支名>
# 如果本地分支名与远程分支名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>

此时使用git push origin master就可以将刚刚修改的推送到远端。


此时远端也出现了刚刚创建的文件。
这里由于我们使用的是SSH协议，是不用每⼀次推送都输入密码的，方便了我们的推送操作。如果你使用的是HTTPS协议，有个麻烦地方就是每次推送都必须输入口令。

拉取

如果远程仓库领先本地仓库时，此时就需要拉取远程仓库的。
Git提供了 git pull 命令，该命令用于从远程获取代码并合并本地的版本。格式如下：

git pull <远程主机名> <远程分支名>:<本地分支名>
# 如果远程分支是与当前分支合并，则冒号后面的部分可以省略。
git pull <远程主机名> <远程分支名>

忽略特殊文件

在日常开发中，我们有些文件不想或者不应该提交到远端，比如保存了数据库密码的配置文件，那怎么让Git知道呢？在Git工作区的根目录下创建一个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件了。不需要从头写 .gitignore 文件，gitee在创建仓库时就可以为我们生成，不过需要我们主动勾选一下：

如果当时没有选择这个选择，在工作区创建一个也是可以的。无论哪种方式，最终都可以得到一个完整的 .gitignore 文件，例如我们想忽略以.so和.ini 结尾所有文件， .gitignore 的内容
如下：

# 可以直接写文件名

*.ini
*.so
!c.so

!c.so表示不忽略c.so
最后将.gitignore提交到远端即可。

git add .
git commit -m"add .gitignore"
git push origin master

接着在新增.ini或者.so结尾的文件，使用git status查看仓库状态时就会提示working tree clean，即没有新增。

此时无法添加，但是我们想添加一个文件怎么办呢？使用git add -f [filename]强制添加。
假如此时a.so文件是要被添加的，可以用 git check-ignore 命令检查：

Git会告诉我们， .gitignore 的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。

git刚开始配置的邮箱能不能不是注册gitee时的邮箱
也是用来溯源的，邮箱如果和gitee里面的邮箱不一致，就会导致没有小绿点

git刚开始配置的user是什么的名字
是一个溯源的名字，表示项目是谁提交的

我git reset到之前的某一个版本，然后再提交要怎么办？？仓库中是不是就没有后来的任何版本的？？