git 简介——初级入门教程

最新推荐文章于 2024-08-29 07:57:42 发布

mendel_liang

最新推荐文章于 2024-08-29 07:57:42 发布

阅读量356

点赞数

分类专栏： git

git 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

参考文章

理解Git 代码管理

Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？

集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟。

分布式版本控制，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。

分布式版本控制系统通常也有一台“中央服务器”，但这个服务器的作用仅仅是用来方便“交换”大家的修改，和代码备份。没有它大家也一样干活，只是交换修改不方便而已。

Git 的使用

克隆

克隆服务器代码到本地（一个完整的版本库）

Git clone ssh://git@ip/xxxx/xxxx.git

git clonessh://git@192.168.169.160/Repo/common/doc/liangydoc.git

分支管理

概念

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。

两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

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

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

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

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

实战

我们创建dev分支，然后切换到dev分支：

$ gitcheckout -b dev

Switched toa new branch 'dev'

gitcheckout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ gitbranch dev

$ gitcheckout dev

Switched tobranch 'dev'

然后，用git branch命令查看当前分支：

$ gitbranch

* dev

master

gitbranch命令会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：

Creating a new branch is quick.

然后提交：

$ gitadd readme.txt

$ gitcommit -m "branchtest"

[dev fec145a] branch test

1 file changed, 1 insertion(+)

现在，dev分支的工作完成，我们就可以切换回master分支：

$ gitcheckout master

Switched tobranch 'master'

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

现在，我们把dev分支的工作成果合并到master分支上：

$ gitmerge dev

Updatingd17efd8..fec145a

Fast-forward

readme.txt | 1 +

1 file changed, 1 insertion(+)

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

合并完成后，就可以放心地删除dev分支了：

$ gitbranch -d dev

Deletedbranch dev (was fec145a).

删除后，查看branch，就只剩下master分支了：

$ gitbranch

* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

分支命令回顾

查看所有分支：git branch –a

创建分支：git branch <name>

切换分支：git checkout <name>

创建+切换分支：git checkout-b <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

本地新建的分支如果不推送到远程，对其他人就是不可见的!

常遇问题

常用命令

git status命令可以让我们时刻掌握仓库当前的状态。

git diff file-name可以查看修改内容.

git log命令显示从最近到最远的提交日志.

工作区和暂存区

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

我们把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

暂存区是Git非常重要的概念，弄明白了暂存区，就弄明白了Git的很多操作到底干了什么。

版本回退

不断对文件进行修改，然后不断提交修改到版本库里，就好比玩RPG游戏时，每通过一关就会自动把游戏状态存盘，如果某一关没过去，你还可以选择读取前一关的状态。有些时候，在打Boss之前，你会手动存盘，以便万一打Boss失败了，可以从最近的地方重新开始。Git也是一样，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

要把当前版本回退到上一个版本就可以使用git reset --hard <commit-id>命令。

然我们用git log再看看现在版本库的状态. 回退的commit-id 之前的log都没有。

如果又想回到以前，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个commit-id是3628164...，于是就可以指定回到未来的某个版本：

你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit-id怎么办？

当你用$ git reset –-hard <commit-id>回退到commit-id1版本时，再想恢复到commit-id2，就必须找到commit-id2的commit id。Git提供了一个命令git reflog用来记录你的每一次命令.