Android基础之git

android android基础 git

tag

git tag命令

列显已有的标签

$ git tag
v1.0
v1.2
...
...

如果一个仓库有非常多的tag，这样看起来很不方便，可以使用模糊匹配。
例如，我们想看1.2.x的所有版本，那么

$ git tag -l 'v1.2.*'
v1.2.1
v1.2.2
v1.2.3
v1.2.4

创建标签

$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v1.0
v1.2
v1.4
...
...

• -a (annotated)指定标签名字
• -m 指定了对应的标签说明

可以不加-m，这个时候，就会进入编辑页面，输入说明

查看标签

git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。

$ git show v1.4
tag v1.4
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sun Feb 8 19:02:46 2009 -0800
    Merge branch 'experiment'

删除标签

$ git tag -d v1.0

推送标签

git push origin [tagname]

$ git push origin v1.5
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag]         v1.5 -> v1.5

一次性推送所有本地标签：

$ git push origin --tags
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
 * [new tag]         v0.1 -> v0.1
 * [new tag]         v1.2 -> v1.2
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw
 * [new tag]         v1.5 -> v1.5

拾遗

壹 tag以及branch的区别

参考：Git Tag以及Branch的区别

什么时候打Tag

当一个release版本发布时

相同点

• tag和branch都是指向一个commit对象

区别

• tag是静态的，位置固定；branch是动态的，可以向前走或者向后回滚。
• 一个branch过程中，可以有多个tag，例如一个release/1.2的分支，可以有多个tag1.2.0、tag1.2.1等等。
• release的时候需要打tag，然后分支可以继续向前开发；这个时候，如果突然有紧急线上问题，可以基于tag来拉去分支开发。开发完成，打包后再merge到分支上，继续开发

贰 merge和rebase区别

Git 之 merge 与 rebase 的区别
图解4种git合并分支方法

merge

          master
            |
1--2--3--4--5  
      |
       --6--7 
            |
          feature

执行下面的命令，feature的节点会变成合成的节点

git checkout feature
git merge master

执行下面的命令，master的节点会变成合成的节点

git checkout master
git merge feature

fast-forward

如果待合并的分支在当前分支的下游，也就是说没有分叉时，会发生快速合并，从test分支切换到master分支，然后合并test分支

git checkout master
git merge test

这种方法相当于直接把master分支移动到test分支所在的地方，并移动HEAD指针

no-ff

如果我们不想要快速合并，那么我们可以强制指定为非快速合并，只需加上--no-ff(no fast forward)参数

git checkout master
git merge –no-ff test

这种合并方法会在master分支上新建一个提交节点，从而完成合并

squash

svn的在合并分支时采用的就是这种方式，squash会在当前分支新建一个提交节点
squash和no-ff非常类似，区别只有一点不会保留对合入分支的引用

git checkout master
git merge –squash test

rebase

危险操作

还是上面的例子

          master,origin/master
            |
1--2--3--4--5  
      |
       --6--7 
            |
          feature,origin/feature

我们假设master和feature都已经push到远程分支了，这个时候，我们执行下面的操作：

git checkout feature
git rebase master

我们的本地仓库就变成了这样：

          master,origin/master
            |
1--2--3--4--5--6`--7`
      |            |
       --6--7   feature
            |
          origin/feature

然后我们push一下（这里可能会push不成功）：

git push origin feature

那么远程仓库也就跟着改变了：

          master,origin/master
            |
1--2--3--4--5--6`--7`
                   |
            feature,origin/feature

之前的提交6和7已经没有了。

那么 假设另一个同事A也在基于feature开发，他的本地仓库是这样的：

          master,origin/master
            |
1--2--3--4--5       feature
      |               |
       --6--7--8--9--10
            |
         origin/feature

然后 A执行要同步远程代码：

git fetch

那么这个时候，A的本地仓库是：

          master,origin/master
            |
1--2--3--4--5--6`--7`
      |            |
      |         origin/feature
      |
      |             feature
      |               |
       --6--7--8--9--10

那么这个时候，A同步feature的代码：

git rebase origin/feature

• 假如6、7rebase到5上有冲突，那么就会我rebase的时候解了一遍冲突，现在每一个同事都需要再次解一遍同样的冲突。
• 6`、7` 和 6、7代码应该是一样，但是却会有冲突。

只有 你的分支上 需要 rebase 的所有 commits 都没有被 push 过，就可以安全地使用 git-rebase来操作。
上面的例子中，feature的6和7 commit都已经push过了，所以不要使用rebase命令。

叁 patch 和 diff

Git 打补丁-- patch 和 diff 的使用（详细）

Git 提供了两种补丁方案，git path和git diff

区别

• git diff生成的UNIX标准补丁.diff文件，
• git format-patch生成的Git专用.patch 文件。
• .diff文件只是记录文件改变的内容，不带有commit记录信息,多个commit可以合并成一个diff文件。
• .patch文件带有记录文件改变的内容，也带有commit记录信息,每个commit对应一个patch文件。

patch

创建

最近几次提交

// 最近的1次commit的patch
git format-patch HEAD^ 
// 最近的2次commit的patch
git format-patch HEAD^^ 
// 也是最后1次commit
// -1表示最后一次提交
// -o表示补丁文件输出的目录。
git format-patch -1 -o /root/patch/
// -5表示将最近5次提交制作成补丁
git format-patch -5 -o /root/patch/

从某commit以来的修改

// 将某次提交（不包含该次提交）之前的所有提交做成补丁
git format-patch de85add54522b7ca3b7ad99c7c5ea24525d39ba0 -o /root/patch/
// 只将该次提交制作称补丁
git format-patch -1 de85add54522b7ca3b7ad99c7c5ea24525d39ba0 -o /root/patch/
// 该次提交之前的3个提交（含本次提交）制作成补丁
git format-patch -3 de85add54522b7ca3b7ad99c7c5ea24525d39ba0 -o /root/patch/

两个commit间的修改

// 将两次提交之间的内容（包含两个commit）全部做成补丁，注意的是两次commit id之前是三个点（...）
git format-patch 7f581e5fabbed21ad8c8ccd3398513d626f01ecf...de85add54522b7ca3b7ad99c7c5ea24525d39ba0e919cd7a -o /root/patch/

分支对比

// -M选项表示这个patch要和那个分支比对
git format-patch -M master 

应用

// 检查patch文件
git apply --stat /root/patch/xxx.patch
// 查看是否能应用成功
git apply --check /root/patch/xxx.patch
// 应用patch
git apply /root/patch/xxx.patch
// 应用patch 不必重新commit
git am -s < /root/patch/xxx.patch

diff

Git diff 常见用法
生成标准的patch，只包含diff信息

创建

比较工作区与暂存区

// 不加参数即默认比较工作区与暂存区
git diff 

比较暂存区与最新本地版本库（本地库中最近一次commit的内容）

git diff --cached  [<path>...] 

比较工作区与最新本地版本库

// 如果HEAD指向的是master分支，那么HEAD还可以换成master
git diff HEAD [<path>...]  

比较工作区与指定commit-id的差异

git diff commit-id  [<path>...] 

比较暂存区与指定commit-id的差异

git diff --cached [<commit-id>] [<path>...] 

比较两个commit-id之间的差异

git diff [<commit-id>] [<commit-id>]

这个要注意commit-id的顺序，比如说

bf123
  ^
  |
ag456

现在最新的commit-id是bf123，

bf123的修改：
1.txt
-------
1
2
3
4
-------
ag456的修改
1.txt
-------
1
2
-------

也就是说最新的bf123，就是给1.txt增加了两行：3和4

那么：

git diff bf123 ag456

这个得到的diff是：

1.txt
-------
1
2
- 3
- 4
-------

也就是得到了，以bf12为基准，ag456相对于它的改变，也就是去掉了3和4

交换一下顺序：

git diff ag456 bf123 

这个得到的diff是：

1.txt
-------
1
2
+ 3
+ 4
-------

也就是得到了，以ag456为基准，bf12相对于它的改变，也就是增加了3和4

所以，一般来说，我们需要的顺序应该是commit-id的正序排列

应用

// 查看是否能应用成功
git apply --check /root/patch/xxx.diff
// 应用diff
git apply /root/patch/xxx.patch

cherry-pick