Git 的常用方法简介

最新推荐文章于 2024-09-11 10:41:52 发布

yby19870627

最新推荐文章于 2024-09-11 10:41:52 发布

阅读量4.6k

点赞数

分类专栏：嵌入式开发相关知识文章标签： git branch whitespace email patch vim

嵌入式开发相关知识专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Git 的常用方法简介--主体是从网上抄来的，进行了些整编修改，向原作者致敬

使用git参与kernel开发

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

其他的 git trees 可以在 http://git.kernel.org/ 找到，点击进去就能看到 GIT URL 。

使用 git

自从 git-1.5.4 ， 'git-xyz' 这种用法就不提倡了，而推荐 'git xyz' 风格。 git 的后续版本中将在make install

时不再安装 'git-xyz' 这些 hardlinks 。

当如果执行 git --exec-path 输出的目录中依然有 git-xyz 这些脚本，你还是可以把这个路径加到 PATH 环境变量中，

这样还能够使用 git-xyz 形式的脚本。

config

------

我的一些简单的配置：

$ git-config user.name "Jike Song"

$ git-config user.email [email]albcamus@gmail.com[/email]

$ git-config core.editor vim

$ git-config core.pager "less -N"

$ git-config color.diff true // 显示 diff 时色彩高亮

$ git-config alias.co checkout // 给 git checkout 取个别名，这样只输入 git co 即可

$ git-config sendemail.smtpserver /usr/bin/msmtp

注意，这会在当前 repository 目录下的 .git/config 中写入配置信息。如果 git-config 加了 --global

选项，配置信息就会写入到 ~/.gitconfig 文件中。因为你可能用不同的身份参与不同的项目，而多个

项目都用 git 管理，所以建议不用 --global 配置。

$ git-val -l // 列出 git 变量

init

----

$ git-init-db // 创建一个 .git/ 目录，初始化一个空的 git 仓库

//这个目录在git-clone时也会创建。也就是说clone时会自动初始化git

//仓库里需要的东西

clone

-----

$ git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git [dir name]

[dir name] 是你想让这个仓库叫什么名字。如果不指定，就会等同于目标仓库的名字。

注意，这种 git server 形式的 repository ，都有一个 filename.git 文件；而对于 *.git 的操作，也可以

针对 .git 所在的目录：

$ mkdir tmp/

$ cd tmp/

$ git-clone ~/Sources/linux-2.6

或者通过 ssh ：

$ git-clone [email]arc@host.xyz.com[/email]:/home/arc/Sources/linux-2.6

此时当前目录下有一个 .git/ 目录 . 以下我们都在 linux-2.6/ 下演示：

pull

----

$ git-pull // 更新本地的 git tree 。如果自从你 clone 了 linus tree 之后， linus tree

//有新的改动，那么把这些更改更新到你的本地tree中

//类似于cvs update

FYI: git-clone 和 git-pull 都会默认调用 git-merge 。

FYI: 每天 git-pull 更新技巧：

1) git-describe ，例如目前是 v2.6.26-rc8-12

2) git-pull -v

3) git-describe ，例如是 v2.6.26-rc8-22

4) git-log -p -10 查看变化

diff

----

$ git-diff /* 列出自己本地的 tree 中已修改、但却未 commit 的改动

这也是产生 patch 的方式 ( 用来提交的 patch 需要先 commit 到自己的 tree 里，

然后 git-format-patch) 。注意，使用 git-diff 产生的 patch 都应该在

patch(1) 时指定 -p1 ，或者直接使用 git-apply 打补丁

选项：

--color diff 语法高亮 ( 可以 git-config color.diff true)

--ignore-space-at-eol 忽略行尾的 whitespace

-b

--ignore-space-change 忽略行尾的 whitespace ，并且认为所有的 whitespace 都是一样的

-w

--ignore-all-space 比较两行的时候，完全忽略 whitespace 。这样，即使是一行有很多

whitespaces ，另一行文字一样但是没有 whitespace ， git 也认为这两

行内容一致。

FYI: diff 不同的 branches

/* 下面这两种写法是一样的，都是列出：与 jike 分支相比， master 分支有哪些不同 */

$ git-diff jike..master

$ git-diff jike master

/* 列出自从 jike 分支从 master 分支脱离以来， master 分支又有过哪些改动 */

$ git-diff jike...master

/*{{{*/ git-diff 的详细用法 :

列出自己的 tree HEAD 和某一个 tag 的不同：

$ git-diff v2.6.22

列出某一个文件，和以前某个 tag 的该文件的不同：

$ git diff v2.6.20 init/main.c

注意结果中 + 表示自己的 tree ， - 表示 2.6.20 的。

列出两个 tags 之间的不同：

$ git-diff v2.6.20..v2.6.21-rc1

列出两个 commits 之间的不同 (Notes ，是这两次 commits 之间的 commits 引入的所有改动 ):

$ git-diff 2a062ab483f5afd764fb20631ee960672946a4be..a44008f2372684bacfab03de5039f68b613c5b53

列出两个 tags 的某一文件的不同：

$ git-diff v2.6.23 v2.6.24-rc1 init/main.c

or:

$ git-diff v2.6.25-rc3:kernel/module.c v2.6.25-rc4:kernel/module.c

or:

$ git-diff v2.6.25-rc3:kernel/module.c HEAD:kernel/module.c

事实上， git-log ， git-whatchanged 等命令都可以这么用。

/*}}}*/

apply

-----

$ git-apply 相当于 patch(1) 命令，不过 git-apply 专门用来 apply 那些用 git-diff 生成的补丁

--check // 不真正打补丁，而只是检查补丁是否能完美的打上

-v //verbose 模式

-R //reverse 模式，也就是拉出这个补丁来 ( 而不是打进去 )

gui

---

$ git-gui

or:

$ gitk //GUI 模式。还有一些不在 git 包中的 git GUI 前端。我觉得基于 Qt 的 qgit 最好用

revision list

-------------

$ git-rev-list <ID> 以时间为顺序，反向列出 revision ID 。也就是先列最新的 commit ID 。

也可以指定列出的数目，例如：

$ git-rev-list -2 971a71bdc9b42e74a5a8ed0433ac27ae92291024

log

---

查看某一文件都被哪些补丁改动过：

$ git-whatchanged -p security/Kconfig

查看某一文件的每一行的作者和 Revision ID ：

$ git-blame security/Kconfig

or:

$ git-annotate security/Kconfig

查看某一版本的某一文件：

$ git-show v2.6.22:init/main.c

查看两个 tags 之间的 log ： (git-shortlog 也可以这么用 )

$ git-log v2.6.25-rc3..v2.6.25-rc4

和 :

$ git-log -p v2.6.24..v2.6.25-rc1 arch/x86/kernel/smp_64.c

和 :

$ git-whatchanged v2.6.24..v2.6.25-rc1 arch/x86/kernel/smp_64.c

查看某版本之后的 log ：

$ git-log v2.6.25-rc4..HEAD //HEAD 可以省略，直接写成 git-log v2.6.25-rc4..

撤销最近的 commit

----------------

$ git-reset HEAD~1 //HEAD~1 这种方式也可以表示为 HEAD^

$ git-diff |git-apply -R -v

注意： 1) git-reset 和 git-revert 不同，后者是把补丁作为另一个 commit 反向打入 tree 中，而 reset

是真正的撤销； 2) 如果撤销最近的 n 次 commits ，就用 git-reset HEAD~<n> ，例如 HEAD~2

回退到某个 tag 或 commit

--------------------

例如目前我的 linux-2.6 里是 :

$ git-desribe

v2.6.26-3465-g5b664cb

我想让它回退到v2.6.26时的状态(程序和ref log 一起回退 ) 。 git-log 搜索 "Linux 2.6.26" 的 commit ID为：

bce7f793daec3e65ec5c5705d2457b81fe7b5725

那么:

$ git-reset --hard bce7f793daec3e65ec5c5705d2457b81fe7b5725

--hard不但会reset你的working tree ，而且联 index files 一起 reset ：整个回到你指定的 commit 状态。

reset/reflog

------------

举例来说， reset 你的当前 branch 的 tip(HEAD 所在的那个 commit)

$ git-reset HEAD^

选项：

--mixed 只撤销掉 index 中的 commit ，却保留那个 commit 对应的内容

--hard index 和 working dir 全撤销，也就是 commit 消失，并且其内容也消失

--soft index 和 working dir 都不动，只 "require them to be in a good order" (

这是man git-reset 中的话，什么意思？ ) 。这会让该 commit 修改的文件变

成"dded but not yet committed" 的状态。

如果不加这3个参数之一，那git-reset默认就是--mixed方式。

/*{{{*/ [FYI] git-reset --hard 之后又想恢复

在 git 中，除非你运行了 git-gc --prune ，否则历史是永远不会被擦除的，你可以随意恢复到任何历史状态。下面就是

一个恢复被 git-reset --hard 擦除了的 commit 的例子：

//reset最近的commit

$ git-reset --hard HEAD^

HEAD is now at bc45eb8 Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

//查看reflog

$ git-reflog

bc45eb8... HEAD@{0}: HEAD^: updating HEAD

a7dc750... HEAD@{1}: commit: [PCI] code cleanup : remove dead pci_remove_device_safe()

bc45eb8... HEAD@{2}: checkout: moving from jike to bc45eb8950b8c14487385cfd2bda1613ca8d9703

//reset回去

$ git-reset --hard HEAD@{1} // 注意， HEAD@{1} 就是我们要恢复的那个状态

HEAD is now at a7dc750 [PCI] code cleanup : remove dead pci_remove_device_safe()

注意也可以把reflog列出来的历史状态checkout出来：

$ git-checkout HEAD@{30} -b new_branch

/*}}}*/

stash

-----

git-stash是个很有趣的功能，它可以让你把目前的dirty内容"隐藏"起来，使得你的仓库看起来是干净的。

这在两种情况下很有用：

1，修改了一个文件，尚未commit，此时又想去修改别的文件；

2，切换到别的branch之前，把尚未commit的改动stash一下，以防git-checkout命令丢弃了你的

未提交的修改。

用法:

$ git-stash

参数：

list // 列出所有 stash 了的项目，注意会显示 stash 的 ID

show [-p] [stash@{<id>}] // 查看某个 stash ， -p 会显示补丁。如果不指定 id ，则 show 最近 stash 的那个

apply [stash@{<id>}] // 恢复某个 stash 。如果不指定 id ，则 apply 最近 stash 的那个

save //stash 当前的未提交的改动

clear // 销毁所有 stash 了的未提交改动

不加参数的话，默认行为就是save。

例如：

$ git-stash list

stash@{0}: WIP on test: 42bb109... a commit to fix. --fixed in git-rebase, "edit"

stash@{1}: WIP on test2: 10253e6... Merge branch 'test' into test2

stash@{2}: WIP on test2: 10253e6... Merge branch 'test' into test2

注意'test'和'test2'都是branch。

$ git-stash show -p stash@{2}

$ git-stash apply stash@{2}

注意，$ git-stash pop 相当于从 stash 栈里头 apply 一个 stash ，亦即： git-stash apply stash@{0}

可以把任一分支的stash给apply到当前分支上。

add

---

新加文件到 index 中，使得 git 可以跟踪它：

$ git-add <filename> // 类似于 cvs add <filename> 。如果<filename>是目录，那么git-add

// 会自动去递归地添加该目录下的所有文件和子目录

$ git-add -a // 本目录下所有文件和子目录

git-add 实际上是对 git-update-index 的调用， git-add hello.c 就相当于：

$ git-update-index --add hello.c

commit

------

$ git-commit -e -s -a

-s 增加 Signed-off-by 行

-e 调用 vim( 我在 .git/config 里制定的 editor) 进行编辑 commit message

-a all

-v 在 vim 中编辑 commit msg 时，连补丁本身也显示在其中

delete

------

删除文件：

$ git-rm aa.c

$ git-commit

撤销一次commit

--------------

$ git-log /* 找到要撤销的 commit ID */

$ git-revert adb2f08089edac8bf1912a618a74485ab42f2b86 // 指定导致删除操作的 commit ID ，进行撤消

列出某一个commit ID 对应的补丁

-----------------------------

$ git-log -1 -p 721151d004dcf01a71b12bb6b893f9160284cf6e

-1 的意思是只显示一个 commit 。如果你想显示 5 个，就 -5 。不指定的话， git log 会从该 commit 一直往后显示。

选项 :

--color diff 语法高亮

or:

$ git-format-patch --stdout -1 721151d004dcf01a71b12bb6b893f9160284cf6e

--stdout 指定 git 写到标准输出，否则会写入到磁盘中。

or:

$ git-show 721151d004dcf01a71b12bb6b893f9160284cf6e

git-shortlog

------------

类似于git-log，只是简略。

git-bisect的用法

----------------

/*{{{*/ $ git-bisect start

$ git-bisect bad // 该版本的 kernel 标记为 bad

或者有针对性的：

/* 只对 2.6.22-rc1 之后、 2.6.22-rc2 之间的 commits 进行 bisect */

$ git-bisect bad v2.6.22-rc1

$ git-bisect good v2.6.22-rc2

LABEL: 在你指定了 bad 和 good 之后，如果这两个版本之间有 1000 个 revisions ， git 就默认剔除了 500个，你应该在此时测试该版本：

创建一个临时性的 output 目录 :

$ make ../git_bisect_output/

编译：

$ make O=../git_bisect_output/ menuconfig

$ make O=../git_bisect_output/ V=1 -j4

$ sudo make O=../git_bisect_output/ V=1 modules_install install

注意，最好在 menuconfig 时，给 local version 加上一个 string ，例如 take1 、 take2 等。

启动新编译的 kernel ，如果还有 BUG ：

$ git-bisect bad

如果没有 BUG 了：

$ git-bisect good

goto LABEL;

直到某个时候，只剩下一个 revision 可以怀疑，那时候就可以确认是它引入了 BUG 。

当 bisect 结束，恢复到 master 版本：

# git-bisect reset

[ 注意 ]

git bisect 是一个漫长而痛苦的过程。我在 Dell Optiplex745(2G 内存 /Core2 双核 2G) 机器上足足做了一天，才定位到一个 BUG 。

[replay 的用法 ]

如果应该输入 git-bisect good 的时候，不小心输入了 git-bisect bad ；或者本应该输入 git-bisect bad 的时候不小心写成了

git-bisect good ，则可以这样回退：

1) git-bisect log | tee ../git.bisect.log

2) 修改 ../git.bisect.log ，删掉最后两行 -- 也就是回退 1 步。如果需要回退 N 步，那就删掉 N 个最后两行

3) git-bisect replay ../git.bisect.log

[visualize 的用法 ]

git-bisect 的时间很长，因为可能需要编译 N 次内核。在此期间，可以用：

$ git-bisect visualize

来在gitk中查看目前还待检验的那些Revs。

FYI: 如果你象我一样更喜欢 qgit ，可以修改 `which git-bisect` 脚本，将 'gitk' 字样替换成 'qgit' 。

/*}}}*/

修改上次commit的log message

---------------------------

// 下面这个方法真土 .. 事实上， git-citool 只是 git-commit 的 GUI 形式

$ git-citool GUI 界面的 git-commit 。不但可以提交，而且可以编辑上次 commit 的信息。

or:

// 修改

$ git-commit --amend

同理，使用git-commit的--amend模式还可以修改last commit 的 * 内容 *.

-> git-stash // 藏起未提交的工作， make your branch looks `clean'

-> 修改文件，直到你满意

-> git-commit -a --amend // 编辑 msg

-> git-stash apply //undo the stash

修改某个commit的msg和内容!!

---------------------------

[WARNING] 修改一个已经不在 HEAD 位置的 commit ，无论是修改其 msg 还是内容，都必须发生在 * 该 commit尚未被

第 2 人看到 * 的情况下，也就是说，没有 push 给别人，也没有被别人 pull 过。

否则，这种修改会造成开发社区的混乱 (think about that...) 。

假定我们同时修改msg和内容:

[FYI] 对于只修改 msg 的情形，也走这个步骤，但是注意 "5, rebase" 的时候，选 edit( 而不是 squash) 即可。

1, 记住那个要修改的 commit ID ， SHA1 串的前 5 个字母即可。例如它是 27675 ；

2, 记住 27675 的前一个 commit ，例如它是 534e3 ；

3, git-show 27675 看看它的内容，并用 Vim 修改相应的文件，改到自己满意为止；

4, 提交改动

$ git-commit -a -m "a new commit, just to be combined with 27675"

假设其ID是12345。

5, rebase

$ git-rebase -i 534e3

这时 git 会调用 vim 来让你编辑，你会看到一行行 "pick 1acb3e <commit msg>" ，这些 commits 都是发生在

我们要在 git-rebase 指定的 534e3 之后的。此时：

-> 如果你删除一行，那么 git-rebase 就会让这个 commit 消失；

-> 如果你删除所有行，那么 git-rebase 就放弃这次操作；

-> 如果你把某一行的 "pick" 改成了 "squash" ，那么 git-rebase 就会把这个 commit * 合并 * 到它的上一行

的 commit 里，并再次调用 Vim 让你编辑合并后的 commit msg 。

-> 如果你把某一行的 "pick" 改成 "edit" ，那么 git 就会让你执行 : a) git-commit --amend ； b) git-rebase

--continue ，这样可以修改其 msg 。注意 SHA1 ID 会改变。

我们需要的就是上面的第 3 种情形。找到 12345 那行，把 pick 改成 squash ，然后 dd 删除该行， p 命令粘贴在 27675

那行的下面， :wq 退出 Vim 。

马上 Git 会再次调用 Vim ，让你编辑合并后的 commit 的 msg 。编辑后保存退出。

6, 再次查看合并后的 commit

$ git-log 查找 msg 或者 git-whatchanged -p <file> 查找补丁

这时你发现新 commit 的 ID 变了，既不是 27675 也不是 12345 ，而是一个新的SHA1 ID 。

desribe

-------

$ git-describe

v2.6.25-rc2-347-g97f7905

merge

-----

git-pull/git-push 会默认调用 git-merge ，一般会成功；如果失败，那就要：

1, 该命令必然失败，因为 confilicts 存在：

$ git-merge

2, 查看冲突 ( 冲突的地方已经像 CVS update 冲突那样，在冲突文件中用>>>>和<<<<标记了)：

$ git-diff

3, 修改冲突文件，改成你想要的样子

4, 更新 index

$ git-update-index

5, commit 这次 merge

$ git-commit -a -e -s