[TOC]

Git 快速入手

---

配置初始化

初次运行 Git 前的配置

一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。

Git 提供了一个叫做 git config 的工具，专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：

• /etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。
• ~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。
• .git/config 文件: 当前工作目录中的 .git/config 文件：这里的配置仅仅针对当前项目有效。
  每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。
  在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。

用户信息

第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：

$ git config --global user.name "heminlin"
$ git config --global user.email "heminlin@serversz.com"

如果用了 --global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 --global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。

• 如何避免每次输入密码
  如果你正在使用 HTTPS URL 来推送，Git 服务器会询问用户名与密码。 默认情况下它会在终端中提示服务器是否允许你进行推送。
  如果不想在每一次推送时都输入用户名与密码，你可以设置一个 “credential cache”。 最简单的方式就是将其保存在内存中几分钟，可以简单地运行 git config --global credential.helper cache 来设置它。

文本编辑器

接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候，会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器，一般可能会是 Vi 或者 Vim。如果你有其他偏好，比如 Emacs 的话，可以重新设置：

$ git config --global core.editor emacs

差异分析工具

还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：

$ git config --global merge.tool vimdiff

Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合并工具的输出信息。当然，你也可以指定使用自己开发的工具，具体怎么做可以google。

查看配置信息

要检查已有的配置信息，可以使用 git config --list 命令：

$ git config --list
user.name=heminlin
user.email=heminlin@serversz.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 /etc/gitconfig 和 ~/.gitconfig），不过最终 Git 实际采用的是最后一个。

也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样：

$ git config user.name
heminlin

工作流程

1. 克隆远程仓库到本地 （git clone ）

做Android源码开发时，拿到芯片公司提供的Android的源码后，我们自己的的代码服务器上会建立一个源码的仓库，并会给工程师配置相应的访问权限。开始开发时，我们首先要做的就是从服务器上获取源码，获取命令如下：

$ git clone -b branch_name git@192.168.0.202:cbc/mt6735_53_v2.47.git you_dir_name
// branch_name  :你需要下载的分支名字，如果运程仓库只有master 分支的话，这里就不用填
// you_dir_name :你本地的项目工作目录名字
// git@192.168.0.202:cbc/mt6735_53_v2.47.git : 这是MT6735 代码仓库的地址，不同平台的地址不一样
//初始化时获取E055的分支到本地E055目录下：
$ git clone -b E055 git@192.168.0.202:cbc/mt6735_53_v2.47.git E055
$ cd E055
    $ git branch
 *E055
// 当前就只有E055的分支在E055的目录下

如果clone 的时候没有加 -b 选项，克隆下来的代码将是默认的master分支。

image.jpg

2. 查看修改与缓存修改 (git status, git add )

• 在修改完某个功能后，本地的代码肯定会跟服务器的不一样了，这时候，你需要把你的修改提交到服务器上，在提交修改之前，你首先要知道这么几件事情:

1. 你的工作目录下的文件有最多有两种类型的文件状态，一种是已经是在跟踪中的，另一种属于没有跟踪的。

2. 跟踪中的文件又分为 已修改， 未修改，已缓存（在暂存区域） 三个状态

    //clone 完代码到本地后，如果没有做任何改动，那当前目前下的所有文件都是处于 跟踪中，都未做修改的状态，
    //用git status 命令可以查看到当前目录下所有文件的状态
    $ git status
    # On branch E055
    nothing to commit (working directory clean）
    // 上面是我们刚clone 下来仓库的状态，没有任何东西需要commit的
   

在我增加文件 new_file , status.txt ，修改了 AppListActivity.java 后,查看状态显示如下：

git_status.png

new_file,status.txt 两个文件是属于未跟踪的文件。
查看本地修改了哪些内容：git diff 或者查看指定文件修改了哪些内容 git diff file_name；git diff 不会显示未跟踪的文件做了哪些修改。

git_diff.png

从上图可以看到我这里只是去掉了一行注释。
在用 git diff 检查完你的修改后，你就可以用add 命令缓存起来了。

git_add.png

从上图可以看到已经把AppListActivity.java提交到缓存区了。这里还显示了2个未跟踪的文件 new_file 和 status.txt，这两个文件是我做测试用的，无关紧要，所以我并不需要把他们缓存起来。但如果是你新增有用的文件，比如图片，新增的类文件等，也要用add 命令把新增的文件变成跟踪状态，才能提交到本地仓库。

• git add 时最好加上文件名或者目录名，否则的话会把当前目录下的所有文件都添加到缓存区 上图的git add 后面就加的是目录名

3. 提交修改到本地仓库(git commit)

在git status 查看到有已缓存的文件时， 用 git commit 命令就可以把缓存区的文件提交到本地仓库
$ git commit -m "修改说明"

4. 提交修改到远程仓库 (git push)

在commit 提交修改到本地仓库后，用git push 命令就可以把本地仓库的分支同步到远程仓库分支
$ git push orgin E055
// E055 是远程仓库的名字，所以这个命令是把当前分支同步到远程的E055分支上

5. 验证你提交的代码

在代码提交后，为保证团队远程仓库代码的正确性，最好是在另建一个本地目录用来验证
$ git fetch origin
$ git rebase origin E055
$ make -j32

6.创建本地和远程分支

在开发过程中，为了给某个客户开发一些定制化的功能，我们需要创建一些不同的分支，以便于维护和开发。下图就是在本地创建分支E055_T并推送分支到远程仓库的截图。

git_branch_add.png

7.打标签

$git tag V1.0.0 //创建一个轻量V1.0.0的版本标签
$git tag -a V1.0.0 -m "这是一个V1.0.0的版本"// 创建带注释的标签，创建标签建议用这个方式
$git tag -d V1.0.0 //删除V1.0.0的版本标签
$git push --tags  //把标签推送到远程
$git tag -l   //查看标签 git tag 也可以

更新代码 （ git rebase ， git pull）

更新代码有2种方式：
1.git pull origin branch_name // 这一条命令就是远程分支合并到本地分支，并更新 HEAD指针。有合并时需要输入合并日志。
2.git fetch origin //获取最新的仓库代码
git rebase origin/branch_name //把当前分支变基到远程仓库的最新引用上。说白了就是让你当前的工作分支建立了服务器最新的代码基础上。
git rebase 是变基的命令，用git rebase 后，会使你的Log 看起来是串行的，而不是并行的。

    $ git checkout E055_Debug
    $ git rebase E055        // 把当前分支变基到E055的最新提交上
    $ git rebase origin/E055 //把当前分支变基到远程分支的最新引用上

git_log.png

上图就是没有用rebase 命令变基的提交记录，可以看到不同工程师基于不同SHA-1版本的提交记录。下图这种串行的记录就是用git rebase 的记录图，历史修改

git_pull_log.png

修改冲突

下面的几张截图是一个简单的冲突处理过程。
下图是我本地做的修改，需要提交到远程仓库，而这时候，别人也修改了这个地方，并且已经提交到了远程仓库，这样我再提交的时候就会出现冲突。我本地做的修改如下：

git_my_changed.png

查看完修改内容后

$git add package/app
$git commit -m "冲突演示4"
$git push origin E055_Temp // 运行这里时，因为运程仓库已经更新会提示需要更新代码后才能提交
$git pull origin E055_Temp // 更新代码并自动合并到当前分支
/* 这里建议是用组合命令来更新。
1,git fetch origin 这里是更新远程仓库的内容到本地
2,git rebase origin/E055_Temp // 把当前工作分支变基到远程的最新HEAD指针上。
*/

push 的时候错误：

git_push_error.png

需要更新代码，在合并或者变基的时候会报错：

git_rebase_error.png

查看当前状态截图如下，可以看到有个both modified 状态的文件

git_both_modify.png

查看文件修改内容：其中

<<<<<<< HEAD
=======
这一组符号之间的代码表示是远程服务器上的代码

=======
>>>>>>> 之间这段表示是你本地需要提交的修改
这两组符号是冲突的标志符，merge代码的时候选择你需要保留的代码，然后去掉这两组标志符后就表示merge成功了。

git_diff_of_merge.png

按照上面的说明，我这里选择保留我本地所做的修改，并去掉所有的<<<<<<< ====== >>>>>这些符号。修改完这个文件后，需要再add进来，表示冲突处理完成，并再次commit。

$git add package/app/
$git rebase --contiune  //如果是用的 git pull 更新的代码，这句就不需要了

git_rebase_continue.png git_log_after_push.png

最后服务器的代码是这样的：

git_diff_after_push.png

注意
上面的截图只是一个简单的冲突处理。在实际开发过程中发生冲突时，需要按照以下步骤来处理：
1.首先查看冲突的地方，选择要保留的代码，遇到不明白或者复杂的地方，需要找提交的工程师弄明白他所做修改的目的。
2.在修改完冲突后，需要在本地验证功能是否正常，有没有影像到别人的修改。
3.验证完后，在执行add，commit，push 等步骤。

撤消操作 （git reset, git checkout）

git_status_after_reset.png

以下是git 官方教程上的内容：

在任何一个阶段，你都有可能想要撤消某些操作。 这里，我们将会学习几个撤消你所做修改的基本工具。 注意，有些撤消操作是不可逆的。 这是在使用 Git 的过程中，会因为操作失误而导致之前的工作丢失的少有的几个地方之一。

有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令尝试重新提交：

$ git commit --amend
这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息。

文本编辑器启动后，可以看到之前的提交信息。 编辑后保存会覆盖原来的提交信息。

例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
最终你只会有一个提交 - 第二次提交将代替第一次提交的结果。

取消暂存的文件
接下来的两个小节演示如何操作暂存区域与工作目录中已修改的文件。 这些命令在修改文件状态的同时，也会提示如何撤消操作。 例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交，但是却意外地输入了 git add * 暂存了它们两个。 如何只取消暂存两个中的一个呢？ git status 命令提示了你：

$ git add *
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

renamed:    README.md -> README
modified:   CONTRIBUTING.md

在 “Changes to be committed” 文字正下方，提示使用 git reset HEAD <file>... 来取消暂存。 所以，我们可以这样来取消暂存 CONTRIBUTING.md 文件：

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

renamed:    README.md -> README

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:   CONTRIBUTING.md

这个命令有点儿奇怪，但是起作用了。 CONTRIBUTING.md 文件已经是修改未暂存的状态了。

NOTE
虽然在调用时加上 --hard 选项可以令 git reset 成为一个危险的命令（译注：可能导致工作目录中所有当前进度丢失！），但本例中工作目录内的文件并不会被修改。 不加选项地调用 git reset 并不危险 — 它只会修改暂存区域。

到目前为止这个神奇的调用就是你需要对 git reset 命令了解的全部。我们将会在 重置揭密 中了解 reset 的更多细节以及如何掌握它做一些真正有趣的事。

撤消对文件的修改
如果你并不想保留对 CONTRIBUTING.md 文件的修改怎么办？ 你该如何方便地撤消修改 - 将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？ 幸运的是，git status 也告诉了你应该如何做。 在最后一个例子中，未暂存区域是这样：

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:   CONTRIBUTING.md

它非常清楚地告诉了你如何撤消之前所做的修改。 让我们来按照提示执行：

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

renamed:    README.md -> README

可以看到那些修改已经被撤消了。

IMPORTANT
你需要知道 git checkout -- [file] 是一个危险的命令，这很重要。 你对那个文件做的任何修改都会消失 - 你只是拷贝了另一个文件来覆盖它。 除非你确实清楚不想要那个文件了，否则不要使用这个命令。

如果你仍然想保留对那个文件做出的修改，但是现在仍然需要撤消，我们将会在 Git 分支 介绍保存进度与分支；这些通常是更好的做法。

记住，在 Git 中任何 已提交的 东西几乎总是可以恢复的。 甚至那些被删除的分支中的提交或使用 --amend 选项覆盖的提交也可以恢复（阅读 数据恢复 了解数据恢复）。 然而，任何你未提交的东西丢失后很可能再也找不到了。