Git使用小结（一）

正好最近在逛GitHub的时候看到了一个学习git的项目，点进去一看，寓教于乐，闯关类型+互动的类型十分的有趣，就用了差不多一天的时间给学完了，感觉收获颇多，然而平时生活中似乎还是git pull， git push用的多，于是寻思着还是得记下来，免得过段时间就忘干净了。整理一下也有助于自己记忆吧。

注：
[argu] 代表此参数可以省略
staged files 表示已经加入git 跟踪的文件但是还未提交到commit文件
working tree 表示当前系统中的文件，未被git处理
commit 已经被commit的文件
HEAD 表示当前git所指向的commit，即“版本指针”

我们假设从零开始，假设一个日常生活的流程来使用吧

1. 首先是初始化,这个命令会在当前目录下初始化一个.git目录,我们大致关注一下.git项目的结构

git init
├── HEAD //存储当前HEAD指针指向的commit，一般是master
├── branches
├── config //文本文件，可以手动配置一些参数（用户名、邮箱，默认的远端分支等等）
├── description
├── hooks
├── info
├── objects
└── refs

2. 接着是增加远端仓库的地址

git remote add
git remote add origin https://www.github.com/userName/repositoryName.git

注意这个origin表示的是远端仓库的名字而非master，本地git可以指定多个remote,例如可以再增加一个mirror: git remote add mirror ...
增加后可以在.git/config文件里看到

[remote "origin"]
    url = https://www.github.com/test/test.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[remote "mirror"]
    url = https://www.github.com/test/test2.git
    fetch = +refs/heads/*:refs/remotes/mirror/*

其中fetch那一行表示的是本地分支与远端分支的对应关系，默认是同名对应，即远端的origin/master对应本地的master

3. 接着是增加一个commit
   首先我们先增加两个修改(Windows下不适用)

echo aaa > a.txt
echo bbb > b.txt

通过git add 来增加本地的修改到工作树里面，一旦新文件被加进去，就会被git跟踪状态(staged)

git add *.txt

接下来就可以git commit 了

git commit -m "Add a.txt and b.txt"

这里顺带介绍下git commit 几个比较重要的可选参数

-m (--message) 增加commit的消息
-a (--all) 把所有修改和删除的文件自动stage(这个命令可以用来省略git add )，对新增文件无效（因为新增文件还没有被stage）
--amend 修改某次commit的信息，不会产生新的commit
--no-edit 表示不更改某次commit的信息（在修改commit的时候才会用到）

例如你提交了commit之后发现自己拼写错误了，为了这个重新生成一个commit怕被同事笑话，那么就可以直接修改代码，然后使用以下命令

git commit -a -amend --no-edit

那么一切就似乎从来没有发生过

4. 那么接下来似乎就应该把自己的修改push到远端了，一个简单的push命令可以解决问题(本文中作为初始化远端仓库的话可用)，但是并非总是最佳的实践，因为你不知道是否已经有人更改过了远端的仓库，可以先使用

git fetch [] []

• remote可省略，省略则默认为origin
• branch可省略，默认为与本地当前的branch名字一致

之后可以用git diff 命令查看两次分支的差异

git diff HEAD origin/master

git diff [] // 查看当前working tree与staged files文件的区别，注意只包含删除与修改的，新增文件未被纳入跟踪
git diff --cached [] [] //查看当前staged files与某次commit的文件的区别，commit可省略，默认为HEAD
git diff [path]//比较working tree files 和某次commit 文件的区别，commit不可省略，否则是第一种情况
git diff [] //比较两次文件的差异

接下来有两个选择

• git rebase 将本地的commit“伪装”成在远端的commit之后发生
  • -- continue:遇到冲突时手动解决后继续rebase
  • -- skip 遇到冲突时跳过
  • -- abort 遇到冲突时中止
• git merge 将本地的commit与远端的commit merge之后形成一个新的merge commit。可能会有冲突，此时需手动解决

git fetch + git merge = git pull
git fetch + git rebase = git pull -- rebase

git merge能保留所有原始记录，而git rebase能使得项目的分支变得简单易读。
选择哪一个并没有定论，个人感觉是如果不是特别重要的两边都需要保留的commit（例如两个人独立开发很久，终于要合并了）的话，选择rebase会是一个比较好的选择。

5. 现在可以进行git push了

git push

先进行第四步保证git push可以成功。

6. 全过程中我们都可以使用Git status来查看状态，它能给出一些提示的命令，且无任何实际效果，对于新手很有帮助，可以多敲这个命令。

git status

总结

到了这一步，日常使用Git的需求基本就得到满足了，我们模拟了新建仓库，pull 和push的操作，如何比较不同，解决冲突等等。
其实git文档齐全，你可以使用git --help 来获取某个命令的详细文档，解释的十分清楚。笔者建议要边学边实践，能够加深认识。
但是如果Git仅仅只有这样的功能是不能够成为最流行的版本管理工具的。Git最强大的功能在于其强大的分支管理。本文中粗略涉及了HEAD，master等分支的名字，merge，rebase等分支合并的行为，但是没有细讲。笔者有意在下一篇中继续详细讲讲git 分支的使用。

下一篇涉及的Git 命令

如何选择“后悔药”：
git revert
git reset

分支管理
git checkout
git branch
git cherry-pick
git rebase -i

其他git常见问题
.gitignore
大小写问题
已经被staged的文件加入gitignore后无效
git 配置问题(local, global)
重写git的提交记录

如果觉得本文对你有帮助的话，请点个喜欢。你的喜欢是对笔者最大的鞭策
如果觉得有任何疑问，可以在评论区里提出。
下转Git使用小结（二）