git教程(1)---本地仓库操作

git安装-Centos

sudo yum -y install git #直接安装git即可

基本操作

git init

仓库是进行版本控制的一个文件目录，创建一个普通目录后进入到此目录中，使用git init操作，表示让git管理此目录。

git init之前：

git init之后：

git config

在安装完git后，首先要做的事情就是配置用户名称和email地址，可以使用以下命令进行配置。

git config [--global] user.name "用户名称"
git config [--global] user.email "邮箱地址"
git config -l  #使用此命令可以查看config配置信息
--global #此选项是一个可选项，如果使用此选项表示在该机器上的所有git仓库都使用该配置

例如：

git config --unset user.name # --unset可以用于删除对应的配置，但是不能删除全局的配置信息

工作区和版本库

工作区

工作区就是在电脑上你要写代码或者文件的目录。

暂存区/索引

暂存区一般存放在.git目录下的index文件中，我们把暂存区有时也叫做索引。

版本库

工作区有一个隐藏的.git目录，它不算工作区，它是git的版本库。这个版本库里面的所有文件都被git管理起来，每个文件的修改，删除，git都能追踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以恢复到之前的版本。

上图中，体现了三者工作区，暂存区，版本库之间的关系。

添加文件—场景一

不能手动将工作区的文件手动添加到版本库中，在工作区进行修改(增加，删除，修改)操作后可以通过add添加到版本库的暂存区中。

例如：在工作区内创建一个文件test1.txt

git status

通过git status 查看仓库的状态

这段话的意思就是在工作区中的test1.txt文件没有被git追踪管理，可以使用git add将其添加到暂存区中。

git add test1.txt //将test1.txt添加到暂存区中
git commit -m"add test1.txt" //将test1.txt添加到版本库

git log

可以通过git log来查看历史提交记录：

git log

git log --pretty=oneline //漂亮的显示

查看.git目录结构

• HEAD：默认存放的是指向master分支的指针
  

• index：暂存区，就是将add的内容添加到这里
  可以使用git ls-files -s查看暂存区中的内容：
  
  注意：在暂存区和分支上存储的都是git对象的索引，git对象的本体存放在objects中，所以暂存区和分支都是比较轻量的。

• refs/heads/master：保存的最新一次的commit id
  

• objects：在版本库中维护的对象库
  针对每次修改，都会将每次修改写入到一个git对象中，而git对象是存放在对象库(objects)中的。
  查看objects目录下的内容：
  
  要想查看某个git对象，首先将此git对象的id分成两部分，前两个字符表示其存放的目录，后38个字符表示其存放的文件。可以查看以下最新提交的commit id 对应的git对象中的内容：
  使用git cat-file -p id号来根据id查看内容
  
  以上就是最新一次提交对应的git对象中的内容。可以看到tree选项后面跟的也是一个git对象的id，可以查看一下其中的内容：
  
  可以看到这个对象中存放的是关于修改test1.txt文件形成的git对象的id，顺便看一下这个git 对象中的内容存放的是什么：
  
  可以看到这个git对象中存放的内容就是对test1.txt文件修改的内容。并且，无论是哪个git对象都是存放在objects目录下的。

添加文件—场景二

touch test2.txt
git add .
touch test3.txt
git commit -m"second commit"
[master 7a19ee2] second commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test2.txt

可以看到，明明在工作区中创建了两个文件，但是在commit后的提示中显示只有1个change。其实也不难理解，因为commit操作是将暂存区的内容提交到分支中，上述操作中在commit之前只将test2.txt添加到了暂存区中，所以结果只有1个change。对于test3.txt可以先add到暂存区在commit到分支上。

修改文件

修改是什么意思呢？对于一个文件新增一些数据，删除一些数据，修改一些数据都代表修改文件，git追踪管理的是一个个修改而不是文件。

比如我们在开发一个项目，在工作区中写了好几天的代码，我们忘记了具体修改了哪些内容，可以使用 git diff 文件名来查看工作区与暂存区这一文件内容的区别。

git diif 展示的结果是一种diff格式：
—a/ 表示修改前的文件名
+++b/ 表示修改后的文件名
-1 +1，3其中-1表示：显示修改前的第一行数据，+1，3表示显示修改后的从第一行开始连续三行的数据。

git diff HEAD -- file查看版本库和工作区文件的区别：

版本回退

git reset命令用于版本的回退操作，本质是对版本库中的内容做回退。

git reset [--soft | --mixed | --hard] [HEAD]
HEAD说明:
HEAD表示当前版本
HEAD^表示上一个版本
HEAD^^表示上两个版本
依次类推......
也可以使用~数字表示：
HEAD~0表示当前版本
HEAD~1表示上一个版本
HEAD~2表示上两个版本
依次类推......

• –sort:只回退版本库的内容

• –mixed:回退暂存区和版本库的内容（默认选项）
  
  例如，将modify test1这个版本使用–mixed选项回退到add test3版本：
  
  此时在工作区中应该是test1.txt的最新版本，暂存区和版本库中不是test1.txt的最新版本

回退到最新版本
  

• –hard:回退所有区域的内容
  
  
  表示退回到上一个版本，可以看到上述提示HEAD已经指向了add test3.txt这一commit id。再次查看git log发现最新次提交的commit id都不见了。
  
  如果要想再次回到modify test1.txt这个版本该如何操作呢？使用git log已经查不到这次的commit id 了
  git reflog指令，记录了本地的每一次提交
  
  
  可以看到又恢复到了modify test1.txt这个版本了。
  

撤销修改

场景一只有工作区有code

• 方法一：手动删除修改的代码。
• 方法二：使用git checkout -- file指令进行工作区代码的回退。
  例如：在test1.txt中新增一条数据，并且不提交到暂存区。
  
  
  使用git checkout -- test1.txt进行撤销操作
  

工作区和暂存区有code

• 方法：使用git reset --mixed HEAD file回退版本库和暂存区到当前版本，然后使用git checkout -- file撤销工作区的修改。
  例如：在test1.txt中增加一条数据，并且add到暂存区：
  
  
  git reset --mixed HEAD 回退暂存区和版本库到当前版本。
  
  git checkout -- test1.txt撤销工作区对test1.txt的修改。
  

所有区域都有code并且没有push到远程仓库

• 方法一：git reset --hard HEAD^回退到上一个版本
• 方法二：git reset --soft HEAD^将版本库回退到上一个版本，这样就转化为商议种情况了
• 方法三：git reset --mixed HEAD^将版本库和暂存区回退到上一个版本，这样就转化为第一种情况了。

删除

[guoye@alicloud gitcode]$ ls
test1.txt  test2.txt  test3.txt
[guoye@alicloud gitcode]$ rm -f test2.txt 

删除文件后会出现两种情况：

• 确实想删除此文件，但是没有删除干净，因为暂存区和版本库中还保存着此文件的信息。
  git rm test2.txt将test2.txt在暂存区中删除，然后commit提交到版本库中即可。

git rm test2.txt
git commit -m"rm test2.txt"

• 不小心误删除了此文件。
  撤销工作区的修改即可，git checkout -- test2.txt
  git rm = rm + add

分支

创建分支

• git branch查看分支：
  
• git branch dev1创建名为dev1的从分支
  
  *代表当前的工作分支，也就是HEAD指针指向的分支

切换分支

• git checkout 分支名
  例如，切换到刚刚创建的dev1分支
  
• 创建并切换分支,git checkout -b dev2，创建名为dev2的分支，并切换到dev2分支上。
  
  在分支dev2上向test3.txt文件中写入一些内容，然后提交到版本库。
  
  
  
  
  

删除分支

• 使用git branch -d dev注意的是不能在工作分支为dev分支时去删除dev分支。
  
  

合并分支

git merge dev将名为dev的分支合并到当前的工作分支。

例如：将dev2分支合并到master分支上。

可以看到，已经成功的将dev2分支合并到了master分支上。在master分支上可以看到在dev2分支上对test3.txt文件修改的内容。

合并冲突

但是并非所有情况都可以像上述情况一样可以直接合并，有时会出现合并冲突的情况。
例如：
1.创建一个新的分支dev4
2.在master上修改test3.txt文件的内容
3.在dev4上修改test3.txt的文件内容
4.合并dev4到master分支

可以看到此时会出现合并冲突。此时查看test3.txt文件的内容：

此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记）可以选择保留master分支上修改的内容，也可以选择保留在dev4分支上修改的内容，当然也可以同时保留两个分支上修改的内容。

合并模式

• ff模式(fast-forward):
  

像这样的合并就是ff模式的合并，但是这样会存在一个问题：就是当把dev2分支删除后，我们无法辨认最新的这次提交是通过merger得来的，还是通过在master修改得到的。所以不推荐使用ff模式合并分支

• no-ff模式：这种模式下就会在merge下生成一个新的commit，这样从分支的历史上就可以看出分支的信息了。
  
  
  
  git log --graph --pretty=oneline --abbrev-commit 打印分支的图示信息
  
  

可以看到删除dev分支后仍然能够看出最新一次提交是通过merge得到的。

bug分支

我们要在dev分支上进行开发，但是开发到一半的时候，突然发现master分支上的代码有bug，而解决次bug通常会创建新的分支去解决，但是dev分支上的代码还没有提交，要怎么办呢？

• 在dev分支上 使用git stash命令，可以将当前工作区的信息进行储藏，被储藏的内容可以在某个时间恢复出来。
  

• 创建fix_dev去解决master分支上的bug。
  

• 将fix_dev分支合并到master分支上。
  

• 将master分支合并到dev分支
  

• 回到dev上，将之前的储藏的工作区内容进行恢复然后继续开发
  可以使用git stash list 查看之前储存的内容

使用git stash pop进行恢复，同时将储存的内容删除，也可以使用git stash apply进行恢复然后使用git stash drop进行删除
  

• 合并dev分支到master分支

• 删除掉fix_dev分支

最后查看一下分支的图形信息：

删除临时分支

某个新创建的分支在没有合并之前，使用git branch -d 分支名是删除不掉的。

可以使用git branch -D dev强制删除dev分支