5分钟学会git

我之前有一份私人git笔记老长老长了, 今天得空, 把它浓缩成5分钟版本.

感觉纯基础性的东西整理成博客差也差不多了, 还有很多凌乱的工作笔记慢慢在一点一点整理放上来吧,

估计下面几篇博客就开始游戏服务器的开发心得之类的了.

本篇博客因为要5分钟撸完git, 所以语言尽量精简, 只说新人必须知道的, 如果要git进阶的, 后面再另写博客说明, 不该说的废话就不说了

安装

sudo apt-get install git

查看状态

比如查看当前分支的状态 : git status, 这条命令也会给很多其他的git命令提示的喔

查看当前在哪个分支 : git branch

b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git branch
master
new_test_branch
* old_demo
plugin

标记为*的那个就是当前分支, 也就是old_demo分支

克隆

比如从我的一个远端github项目克隆一份到本地 : git clone git@github.com:nosix1992/Flock-AI-Fish-Unreal-VR.git

这个地址是这样得来的, 如图 :

分支

比如创建一个新的分支test_branch : git branch test_branch

比如切换到分支test_branch : git checkout test_branch

比如把test_branch合并到主分支master上来 : 先切换到master上来git checkout master 然后

git merge test_branch

git rebase test_branch

rebase 跟 merge 的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是 merge ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是 rebase ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。各有好处的，不同的团队根据不同的需要以及不同的习惯来选择就好。

比如删除分支test_branch :

git branch -d test_branch

git branch -D test_branch

有些时候可能会删除失败，比如如果a分支的代码还没有合并到master，你执行 git branch -d a 是删除不了的，它会智能的提示你a分支还有未合并的代码，但是如果你非要删除，那就执行 git branch -D a 就可以强制删除a分支。

提交

比如将修改之后的文件test_file加入到暂存区里 : git add test_file

撤销刚刚的git add(也就是说把test_file从暂存区中移出) : git reset HEAD test_file

比如将暂存区里的提交并加入提交信息”update test_file” : git commit -m “update test_file”

把git commit撤销 :

只是把commit撤销并且把文件从暂存区中移出, 但保留已有的文件更改[/b] : 通用命令为 git reset commit_id, 这个commit_id用git log命令来查看, 比如要恢复到刚刚提交的上一次提交的版本, 就用git reset HEAD^(这句命令的意思是说: 恢复到commit id 为HEAD^的版本, HEAD是指向最新的提交，上一次提交是HEAD^,上上次是HEAD^^,也可以写成HEAD～2 ,依次类推. )

把commit撤销且不保留已有的文件更改 : git reset –hard commit_id

比如只是撤销某个文件test_file的修改 : git checkout –test_file

将代码推到远端 : 这之前的所有这些add, commit都是本地仓库的操作, 比如我们把本地的master分支推到github的那个项目的master分支 : git push origin master

贮藏stash

设想一个场景，假设我们正在一个新的分支做新的功能，这个时候突然有一个紧急的bug需要修复，而且修复完之后需要立即发布。当然你说我先把刚写的一点代码进行提交不就行了么？这样理论上当然是ok的，但是这会产品垃圾commit，原则上我们每次的commit都要有实际的意义，你的代码只是刚写了一半，还没有什么实际的意义是不建议就这样commit的，那么有没有一种比较好的办法，可以让我暂时切到别的分支，修复完bug再切回来，而且代码也能保留的呢？

试试git stash吧

git stash : 把当前的文件改动贮藏起来

git stash list: 查看当前有哪些贮藏记录

git stash pop stash_list_id: 会帮你把代码还原，还自动帮你把这条 stash 记录删除

b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git checkout old_demo
error: Your local changes to the following files would be overwritten by checkout:
README.md
Please, commit your changes or stash them before you can switch branches.
Aborting
b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git stash
Saved working directory and index state WIP on new_test_branch: b3ad5d2 modify md
HEAD is now at b3ad5d2 modify md
b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git checkout old_demo
Switched to branch 'old_demo'
Your branch is up-to-date with 'origin/old_demo'.
b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git checkout new_test_branch
Switched to branch 'new_test_branch'
b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git stash list
stash@{0}: WIP on new_test_branch: b3ad5d2 modify md
b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git stash pop stash@{0}
On branch new_test_branch
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
Dropped stash@{0} (88cd440c10c80bb6eaef9f4d86ab4a0be3d6dc00)

对比diff

比如查看当前还未git add的文件的不同 : git diff

比如查看当前已经add 没有commit 的改动 : git diff –cached

比如查看当前所有改动和HEAD的区别(当前还未git add的文件的改动和当前当前已经add 但没有commit 的改动), 也就是上面两条命令的合并 : git diff HEAD

比如查看 commit_id为a和commit_id为b的temp文件夹的差异 : git diff a b temp

处理冲突

假设这样一个场景，A和B两位同学各自开了两个分支来开发不同的功能，大部分情况下都会尽量互不干扰的，但是有一个需求A需要改动一个基础库中的一个类的方法，不巧B这个时候由于业务需要也改动了基础库的这个方法，因为这种情况比较特殊，A和B都认为不会对地方造成影响，等两人各自把功能做完了，需要合并的到主分支 master 的时候，我们假设先合并A的分支，这个时候没问题的，之后再继续合并B的分支，这个时候想想也知道就有冲突了，因为A和B两个人同时更改了同一个地方，Git 本身他没法判断你们两个谁更改的对，但是这个时候他会智能的提示有 conflicts

就像下面这种情况 :

b@b-VirtualBox:~/git_test_link/Flock-AI-Fish-Unreal-VR$ git merge plugin
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

打开READ.md文件一看发现冲突的地方如下:

<<<<<<< HEAD
mmmp
=======
nani
>>>>>>> plugin

冲突的地方由 ==== 分出了上下两个部分，上部分一个叫 HEAD 的字样代表是我当前所在分支的代码，下半部分是一个叫 plugin 分支的代码，可以看到 HEAD 是那里加了一行mmmp，而plugin分支则加了一句nani, 所以我们得跟团队的其他人商量一下看看要改成什么样，而且同时也要把那些 «< HEAD、==== 以及 »»»plugin 这些标记符号也一并删除，最后进行一次 commit 就ok了。

标签tag

主要介绍附注标签( annotated tag)

创建附注标签

git tag -a v0.1.2 -m “0.1.2版本”

创建轻量标签不需要传递参数，直接指定标签名称即可。

创建附注标签时，参数a即annotated的缩写，指定标签类型，后附标签名。参数m指定标签说明，说明信息会保存在标签对象中。

切换到标签

与切换分支命令相同，用git checkout [tagname]

查看标签信息

用git show命令可以查看标签的版本信息：

git show v0.1.2

删除标签

误打或需要修改标签时，需要先将标签删除，再打新标签。

git tag -d v0.1.2 # 删除标签

参数d即delete的缩写，意为删除其后指定的标签。

给指定的commit打标签

打标签不必要在head之上，也可在之前的版本上打，这需要你知道某个提交对象的校验和（通过git log获取）。

git tag -a v0.1.1 9fbc3d0

标签发布

通常的git push不会将标签对象提交到git服务器，我们需要进行显式的操作：

git push origin v0.1.2 # 将v0.1.2标签提交到git服务器

git push origin –tags # 将本地所有标签一次性提交到git服务器