git学习笔记

简介

Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同， 它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

学习文档：

中文教程：

http://www.linuxsir.org/main/doc/git/gittutorcn.htm

Turorial：

http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

core-tutorial:

http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html

everyday git:

http://www.kernel.org/pub/software/scm/git/docs/everyday.html

常用命令

创建版本库

git init version_db_name

抓取远程版本库

git fetch <remote-repository>

添加文件到版本库,只是刷新了跟踪信息，并未真添加

git add some_file_path

清除文件到版本库,只是刷新了跟踪信息，并未真添加

git rm some_file_path

提交跟踪信息，使跟踪信息执行

git commit -m"message" som_file_path

取出提交过的东西覆盖掉当前的文件

git-checkout -f foo.c

查看版本状态信息

git status

查看版本之间的差异

git diff some_file_path

默认的主干为master，可以认为是一个特殊的分支，创建分支命令：

git branch branch_name

切换到分支：

git checkout branch_name

删除分支

git branch -d branch_name

版本库中每个分支的世系发展状态

git show branch_name

git show-branch

版本库中分支的差异

git diff branch_name1 branch_name2

合并分支

git-merge "merge message" HEAD branch_name

或者

git pull . branch_name

合并中如果发生冲突，要解决冲突，然后提交

git commit -i conflict_file_path

在现有的主干上进行分支拷贝

git checkout -b new_branch_name

将已经提交的东西重新逆转至“已更新但未提交（Updated but not Check in）”的状态。 

git-reset --soft HEAD^

恢复提交

git-commit -a -c ORIG_HEAD

为版本库打包

主要是方便在网络上的传输，对.git/objects/ 里面的对象进行打包

git repack

删除打过包的对象

git prune-packed

 

协同工作

 

通过电子邮件交换工作协同开发

git clone http://www.bitsun.com/git/gittutorcn.git

默认地，它会有两个分支： master 和 origin，你可以直接在 master 下展开工作， 也可以创建你自己的工作分支，但是千万不要修改 origin 分支，切记！ 因为它是公共版本库的镜像，如果你修改了它， 那么就不能生成正确的对公共版本库的 patch 文件了。

$ git fetch origin    (1)

$ git rebase origin    (2)

$ git format-patch origin     (3)

(1)更新 origin 分支，防止 origin 分支不是最新的公共版本，产生错误的补丁文件；

(2)将你在 master 上提交的工作迁移到新的源版本库的状态的基础上；

(3)生成补丁文件；

会在当前目录下生成一个补丁文件, 建议你用文本工具查看一下这个文件的具体形式，然后将这个文件以附件的形式发送到项目维护者的邮箱

当项目的维护者收到你的邮件后，只需要用 git-am 命令，就可以将你的工作合并到项目中来。

$ git-checkout -b buddy-incomming

$ git am 补丁文件路径

Git 协同工作

假设 Alice 在一部机器上自己的个人目录中创建了一个项目 /home/alice/project, Bob 想在同一部机器自己的个人目录中为这个项目做点什么。做完修改后通知Alice

git fetch /home/bob/myrepo master:bob-incoming

这个命令将 Bob 的 master 分支的导入到名为 bob-incoming 的分支中

git whatchanged -p master..bob-incoming

将 Bob 的 master 分支的导入到名为 bob-incoming 的分支中

将 "bob-incoming" 分支的东西导入到 Alice 自己的版本库中的， 稍后，Bob 就可以通过下面的命令同步 Alice 的最新变化。

git checkout master

git pull . bob-incoming

项目开发的模式

项目领导人（project lead）的工作

在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。

准备一个能让大家访问的公共版本库。

如果其他人是通过默协议的方式（http）来导入版本库的，那么你有必要保持这个 默协议的友好性。 git-init-db 之后，复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用，但是 post-update 默认是不能唤起它自身的。 通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。

将你的主版本库推入公共版本库。

git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线， 可能的话，执行一下 git-prune，要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。

在你的主版本库中开展工作，这些工作可能是你自己的最项目的编辑， 可能是你由 email 收到的一个补丁，也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。

你可以在任何你喜欢的时候重新打包你的这个私人的版本库。

将项目的进度推入公共库中，并给大家公布一下。

尽管一段时间以后，"git-repack" 公共库。并回到第5步继续工作。

项目的子系统负责人（subsystem maintainer）也有自己的公共库，工作流程大致如下：

准备一个你自己的工作目录，它通过 git-clone 克隆自项目领导人的公共库。 原始的克隆地址（URL）将被保存在 .git/remotes/origin 中。

准备一个可以给大家访问的公共库，就像项目领导人所做的那样。

复制项目领导人的公共库中的打包文件到你的公共库中， 除非你的公共库和项目领导人的公共库是在同一部主机上。 以后你就可以通过 objects/info/alternates 文件的指向来 浏览它所指向的版本库了。

将你的主版本库推入你的公共版本库，并运行 git-repack， 如果你的公共库是通过的公共库是通过 pull 来导入的数据的话， 再执行一下 git-prune 。

在你的主版本库中开展工作。这些工作可能包括你自己的编辑，来自 email 的补丁， 从项目领导人，“下一级子项目负责人”的公共库哪里导入的工作等等。

你可以在任何时候重新打包你的私人版本库。

将你的变更推入公共库中，并且请“项目领导人”和“下级子系统负责人”导入这些变更。

每隔一段时间之后，git-repack 公共库。回到第 5 步继续工作。

“一般开发人员”无须自己的公共库，大致的工作方式是：

准备你的工作库，它应该用 git-clone 克隆自“项目领导人”的公共库（ 如果你只是开发子项目，那么就克隆“子项目负责人”的）。 克隆的源地址（URL）会被保存到 .git/remotes/origin 中。

在你的个人版本库中的 master 分支中开展工作。

每隔一段时间，向上游的版本库运行一下 git-fetch origin 。 这样只会做 git-pull 一半的操作，即只克隆不合并。 公共版本库的新的头就会被保存到 .git/refs/heads/origins 。

用 git-cherry origin 命令，看一下你有什么补丁被接纳了。 并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。

用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。 回到第二步接着工作。