git基础教程(linux)

1.git简介

git 分布式版本控制
git两大特点：
版本控制：支持多人同时开发
分布式：

2.安装与配置

安装

sudo apt-get install git

安装成功，运行如下命令：

git

3.创建一个版本库

(1)新建一个目录git_test，在git_test目录下创建一个版本库：

git init

4.版本创建与回退

4.1 使用

(1)在git_test目录下创建一个文件code.txt
(2)创建一个版本：

git add code.txt
git commit -m ‘版本1’

(3)查看版本记录：

git log

(4)继续编辑code.txt，在里面增加一行
(5)使用如下命令再创建一个版本并查看版本记录：

git add code.txt
git commit -m '版本2'
git log
git log --pretty=oneline

(6)现在若想回到某一个版本，可以使用如下命令：

git reset --hard HEAD^

其中HEAD表示当前最新版本，HEAD^ 表示当前版本的前一个版本，HEAD^^表示当前版本的前前个版本，也可以使用HEAD ~1表示当前版本的前一个版本，HEAD ~100表示当前版本的前100版本。
执行命令后使用git log查看版本记录，发现现在只能看到版本1的记录，cat code.txt查看文件内容，现在只有一行，也就是第一个版本中code.txt的内容。
(7)假如我们现在又想回到版本2，使用命令：

git reset --hard 版本号

(9)假如之前版本2的版本号看不到了，再回到版本2，使用以下命令查看操作记录：

git reflog

4.2 工作区和暂存区

4.2.1工作区（working directory）

电脑中的目录，比如git_test ，就是一个工作区

4.2.2版本库（Repository）

工作区中有一个隐藏目录.git，这个不是工作区，而是git的版本库。
git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
因为我们创建git版本库时，git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放在暂存区，然后，一次性提交暂存区的所有修改。

前面讲了我们把文件往git版本库里添加的时候，是分两步执行的：
第一步是用git add 把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit 提交更改，实际上就是把暂存区的所有内容提交到当前分支。
(1)下面在git_test目录下再创建一个文件code2.txt，然后编辑内容
(2)然后再编辑code.txt内容，在其中加入一行
(3)使用命令查看当前工作区的状态：

git status

显示code.txt被修改，而code2.txt没有被跟踪
(4)使用命令把code.txt和code2.txt加入暂存区（git add code.txt code2.txt），然后再执行git status 命令

(5)然后，执行git commit就可以一次性把暂存区的所有修改提交到分支创建一个版本

(6)一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的。执行命令git status

4.3管理修改

git管理文件的修改，它只会提交暂存区的修改来创建版本。
（1）编辑code.txt，并使用git add 命令将其添加到暂存区中。
（2）继续编辑code.txt，并在其中添加一行。

（3）git commit 创建一个版本，并使用git status 查看，发现第二次修改code.txt内容之后，并没有将其添加到暂存区，所以创建版本的时候并没有被提交。

4.4撤销修改

（1）继续上面的操作，提示我们可以使用git checkout – <文件>来丢弃工作区的改动。执行如下命令，发现工作区干净了，第二次的改动内容也没有了。

（2）我们继续编辑code.txt并在其中添加内容，并将其添加到暂存区。
（3）git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉，重新放回工作区。

（4）现在若想丢弃code.txt的修改，执行命令：

git checkout -- code.txt

现在，如果你不但改错了东西，还从暂存区提交到了版本库，则需要进行版本回退。
小结：
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令：git checkout – file
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节（git reset --hard HEAD^）。

4.5对比文件的不同

对比工作区和某个版本中文件的不同：
（1）继续编辑文件code.txt，在其中添加一行内容
（2）现在要对比工作区中code.txt和HEAD版本中code.txt的不同。使用命令：

git diff HEAD -- code.txt

（3）使用命令丢弃工作区的改动。

git checkout -- code.txt

对比两个版本间文件的不同：
（1）现在要对比HEAD和HEAD^版本中code.txt的不同，使用命令：

git diff HEAD HEAD^ -- code.txt

4.6 删除文件

（1）我们把目录中的code.txt删除

rm code2.txt

这个时候，git知道删除了文件，因此，工作区和版本库就不一致了，git status 命令会立刻提醒哪些文件被删除了。
（2）现在有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit:
另一种情况是删错了，可以直接使用git checkout – code2.txt，这样文件code2.txt又回来了。

小结：
命令git rm 用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

5.分支管理

5.1概念

5.2创建与合并分支

git把我们之前每次提交的版本串成一条时间线，这条时间线就是一个分支。截止到目前只有一条时间线，在git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

（1）一开始的时候，master分支是一条线，git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
（2）当我们创建新的分支，例如dev时，git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

git创建一个分支很快，因为除了增加一个dev指针，改变HEAD的指向，工作区的文件都没有任何变化。
（3）不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

（4）假如我们在dev上的工作完成了，就可以把dev合并到master上。git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

git合并分支也很快，就改改指针，工作区内容也不变。
（5）合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

案例：
（1）执行如下命令可以查看当前有几个分支并且看到在哪个分支下工作。
git branch
（2）下面创建一个分支dev并切换到其上进行工作。
（3）下面我们修改code.txt内容，在里面添加一行，并进行提交。

（4）dev分支的工作完成，我们就可以切换回master分支：

git checkout master

查看code.txt，发现添加的内容没有了。因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
（5）现在，我们把dev分支的工作成果合并到master分支上：

git merge dev

git merge命令用于合并指定分支到当前分支。合并后，再查看code.txt的内容，就可以看到，和dev分支的最新的提交是完全一样的。

注意上面的Fast-forword信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快
（6）合并完成后，就可以放心地删除dev分支了，删除后，查看branch，就只剩下master分支了。

小结：

#查看分支：
git branch
#创建分支：
git branch < name >
#切换分支：
git checkout < name >
#创建+切换分支：
git checkout -b < name >
#合并某分支到当前分支：
git merge < name >
#删除分支：
git branch -d < name >

5.3 解决冲突

合并分支往往不是一帆风顺的。
当两个分支都有了新的提交记录并且修改的时同一个文件时，合并分支就会发生冲突。
（1）再创建一个新分支dev。

（2）修改code.txt内容，并进行提交。
（3）切换回master分支。
（4）在master的code.txt添加一行内容并进行提交。
现在，master分支和dev分支各自都分别有新的提交，变成了这样：

这种情况下，git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。
（5）执行如下命令尝试将dev分支合并到master分支上来。

git告诉我们，code.txt文件存在冲突，必须手动解决冲突后再提交。
（6）git status也告诉我们冲突的文件
（7）查看code.txt的内容。
（8）git用<<<<<<<, ======== ,>>>>>>>>标记出不同分支的内容，我们修改如下后保存：

（9）再提交
（10）现在，master分支和dev分支变成了下图所示：

（11）用带参数的git log也可以看到分支的合并情况：
（12）最后工作完成，可以删除dev分支。

5.4分支管理策略

通常，合并分支时，如果可能，git会用fast forward模式，但是有些快速合并不能成功而且合并时没有冲突，这个时候会合并之后并做一次新的提交。但这种模式下，删除分支后，会丢掉分支信息。
（1）创建切换到dev分支下。
（2）新建一个文件code3.tx编辑内容如下，并提交一个commit。
（3）切换回master分支，编辑code.txt并进行一个提交。
（4）合并dev分支的内容到master分支。
（5）出现如下提示，这是因为这次不能进行快速合并，所以git提示输入合并说明信息，输入之后合并内容之后git会自动创建一次新的提交。
（6）使用分支命令查看分支信息。

（7）删除dev分支

如果要强制禁用fast forwad模式，git就会在merge时生成一个新的commit，这样，从分支历史上可以看出分支信息。
（1）创建并切换到dev分支。
（2）修改code.txt内容，并提交一个commit。
（3）切换回master分支。
（4）准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward:
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
（5）合并后，我们用git log看看分支历史：
可以看到，不使用fast forward模式，merge后就像这样：

如果直接使用fast forward模式，命令：git merge dev。执行结果：

5.5Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
（1）当你接到一个修复一个代号001的bug的任务时，很自然地，你想创建一个分支bug-001来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
（2）git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

（3）首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

（4）现在修复bug，把the new line删掉，然后提交
（5）修复完成后，切换到master分支，并完成合并，最后删除bug-001分支。


（6）现在bug-001修复完成，是时候接着回到dev分支干活了！
（7）工作区是干净的，刚才的工作现场存到哪里去了？用git stash list命令看看：
工作现场还在，git把stash内容存在某个地方了，但是需要恢复一下。

git stash pop

小结：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，恢复工作现场。

6使用github

6.1创建仓库

6.2添加ssh账户

6.3克隆项目

git clone 

6.4上传分支

git push origin 分支名称

6.5将本地分支跟踪服务器分支

git branch --set-upstream-to=origin/远程分支名称 本地分支名称
git push

6.6从远程分支上拉取代码

git pull origin 分支名称

master:用于保存发布的项目代码。v1.0,v2.0
dev:保存开发过程中的代码。

git的一些命令

开始一个工作区（参见：git help tutorial）
clone 克隆仓库到一个新目录
init 创建一个空的git仓库或重新初始化一个已存在的仓库

在当前变更上工作（参见：git help everyday）
add 添加文件内容至索引
mv 移动或重命名一个文件、目录或符号链接
restore 恢复工作区文件
rm 从工作区和索引中删除文件
sparse-checkout 初始化及修改稀疏检出

检查历史和状态（参见：git help revisions）
bisect 通过二分查找定位引入bug的提交
diff 显示提交之间、提交和工作区之间的差异
grep 输出和模式匹配的行
log 显示提交日志
show 显示各种类型的对象
status 显示工作区状态

扩展、标记和调校您的历史记录
branch 列出、创建或删除分支
commit 记录变更到仓库
merge 合并两个或更多开发历史
rebase 在另一个分支上重新应用提交
reset 重置当前HEAD到指定状态
switch 切换分支
tag 创建、列出、删除或校验一个GPG签名的标签对象

协同（参见：git help workflows）
fetch 从另外一个仓库下载对象和引用
pull 获取并整合另外的仓库或一个本地分支
push 更新远程引用和相关的对象

Git中的Patch（补丁）功能允许用户将不同分支或提交之间的更改保存为一种可重用的文件格式。通过使用Patch，您可以将您的更改发送给其他人进行审核或协作，以及在不同的Git仓库或版本控制系统之间导出或导入更改。

7在Git中，使用以下命令来创建和应用Patch：

1、创建Patch
$ git diff > mypatch.patch
使用上面的命令，Git会生成一个名为“mypatch.patch”的文件，其中包含当前工作目录的所有更改。您也可以使用以下命令来创建特定分支或提交之间的Patch：

$ git diff branch1…branch2 > mypatch.patch
$ git diff commit1…commit2 > mypatch.patch
2、应用Patch
要将Patch应用到另一个Git仓库或分支，可以使用以下命令：

$ git apply mypatch.patch
使用上面的命令，Git会尝试将Patch中的更改应用到当前分支中。如果存在冲突，可以手动解决这些冲突并再次 运行“git apply”命令来应用Patch。

您还可以使用“git am”命令将Patch作为Git提交应用：

$ git am mypatch.patch
使用上面的命令，Git会将Patch应用到当前分支，并将其作为新的Git提交记录保存下来。

需要注意的是，Patch是一种文本文件格式，因此它可能会因为不同的操作系统或文本编辑器而有所不同。在创建和应用Patch时，应尽量使用相同的编码格式和行尾符号，以免出现意外的错误或冲突。

8 git reset命令

git reset命令用于回退版本，可以指定退回某一次提交的版本。
fit reset 命令语法格式如下：
fit reset [ --soft | --mixed | --hard] [HEAD]

–mixed为默认，可以不用带该参数，用于重置暂存区的文件与上一次的提交（commit）保持一致，工作区文件内容保持不变。
git reset [HEAD]
实例：

git reset HEAD^#回退所有内容到上一个版本
git reset HEAD^ hello.php#回退hello.php文件的版本到上一个版本
git reset 052e #回退到指定版本

–soft 参数用于回退到某个版本：
git reset --soft HEAD
实例：

git reset --soft HEAD~3 #回退上上上一个版本

–hard 参数撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一个版本，并删除之前的所有信息提交：
git reset --hard HEAD 等价于 git reset --hard
实例：

git reset --hard HEAD~3 #回退上上上一个版本
git reset --hard bae128 #回退到某个版本回退点之前的所有信息
git reset --hard orgin/master #将本地的状态回退到和远程的一样

注意：谨慎使用 --hard参数，它会删除回退点之前的所有信息。
git reset HEAD 命令用于取消已缓存的内容。