[hellogcc] Re: git使用简介
- From: Yao Qi <qiyaoltc@xxxxxxxxx>
- To: hellogcc@xxxxxxxxxxxxx
- Date: Fri, 21 Oct 2011 09:00:49 +0800
On Thu, Oct 20, 2011 at 10:12:24AM +0800, Liu wrote:
> 给我们公司的人做了git培训，顺便写了一个。
很不错。git的文档网上到处都是，我们能不能结合自己的工作，介绍
如何使用git。
比如，在gcc开发，如何使用git-svn
git svn rebase
git svn dcommit 等等。
>
> \section{git基本配置}
> 运行下列命令来配置你的git客户端，就是填写个人基本信息和基本工具。
> \begin{itemize}
> \item git config --global user.name "Your Name"
> \item git config --global user.email yournick@xxxxxxxxxxx
> \item git config --global core.editor YourFavoriteEditor
这里需要说一下，core.editor 一般就是vim，但是可以设置为一些特殊
脚本。这样在你 git commit 的时候，那个脚本运行，可以自动生成
changelog entry等等。
>
> \section{参与你没有写权限的开源项目}
> 先说一下流程，把思路理清楚了，省得废话。
> \begin{itemize}
> \item clone项目代码。
> \item 新建并切换到自己的分支。
> \item 修改，并提交到本地。
> \item 生成补丁。
> \item 把补丁发给maintainer。
> \item 你的补丁被接受之后，切换回主分支，删除自己的开发分支。
> \end{itemize}
>
> 按照上面的流程，我们来看对应的命令。
> \begin{itemize}
> \item git clone URL
> \item git co -b BRANCH\\
> 相当于\\
> git br BRANCH 新建分支\\
> git co BRANCH 切换到分支BRANCH
> \item 修改代码，这个不用说了吧？\\
> git st 查看你对哪些文件做了修改\\
> git add MODIFIED\_FILE
> git ci -m "MSG" 把你的修改提交到本地
> \item git format patch 会自动生成补丁
一般在format patch之前，最好 git rebase -i master 一下
1. 可以把一些小commit cmobine在一起，
2. 修改commit log，把changlog加入 commit log中，这样，
git format patch出来的patch，就带changelog了。
> \item
> 把补丁作为附件mail给maintainer，Linux内核开发最蛋疼的是Linus要求小补丁作为邮件正文，擦，蛋疼，反正我也不玩儿内核，不管那么多。
这里有两个办法
1. git send-mail 可以把patches发出去。我没有用过。
2. 手动inline patch到mail。这个需要mail
client有一些修改。我以thunderbird为例子。 需要在thunderbird
中，关闭auto wrapping。 这个会自动把超过76个的字母的行给加上
换行。
在bash中 $ cat 0001-foo.patch | xclip
然后把光标放在邮件末尾，signature后边,
按下鼠标中键。patch就paste进来了。
> \item git co master 切换回主分支\\
> gir br -D BRANCH 删除自己的开发分支
> \end{itemize}
>
> \section{参与你有写权限的项目中使用git}
> 这不是git-svn，有了git之后，Who fucking care about CVS/SVN?
>
> 同样先说一下流程，把思路理清楚了，省得废话。
> \begin{itemize}
> \item clone项目代码。
> \item 新建并切换到自己的分支。
> \item 修改，并提交到本地。
> \item 把你的分支推送到服务器。
> \item 通知maintainer合并你的分支。
> \item 如果maintainer没有删除你的分支，切换回主分支，并自己删除自己的分支。
> \end{itemize}
这样的情况对于gcc/gdb，不多。能够把一个branch
merge过来的人，都是少数，像Ian那样的。我们大多数工作的时候，是有自己
的branch，上边有若干local patches，每次review结束，可能只有一部分patch，
而不是整个branch的patch都被approve了。 这个时候需要git cherry-pick 从
你的branch挑选几个commit到master，然后push。
>
> 下面的命令跟上一节相同的不再解释。
> \begin{itemize}
> \item git clone username@URL\\
> 因为你有写权限了，所以clone的时候，加上你的username
> \item git co -b BRANCH
> \item git ci -a -m "MSG"\\
> 相当于\\
> git add ALL\_MODIFIED\_FILES\\
> git ci -m "MSG"\\
> 如果有新建的文件或者目录，你还是需要\\
> git add NEW\_FILE/DIR
> \item git push origin BRANCH:BRANCH 把你的分支推送到服务器
> \item 通知maintainer合并你的分支，通讯基本靠吼，打电话，发邮件，都行吧。
> \item 如果maintainer没有删除你的分支\\
> git co master 切换回主分支\\
> git push origin :BRANCH 自己删除自己的远程分支\\
> git br -D BRANCH 自己删除自己的本地分支
> \end{itemize}
>
> \section{管理你的git项目}
> 如果你的项目里面有contributor、maintainer、commiter，你还做什么？只有两件事情了，合并分支，打release标签。
> \begin{itemize}
> \item git merge BRANCH\\
> 在master分支运行这个命令，就是合并了
> \item git tag TAG 1b2e1d63ff\\
>
> 就是打标签了，虽然git的分支功能非常强大，但是我们每个release应该都是一个TAG，而不是一个branch啊，当然，也许有人希望继续维护某个release版本的branch的，可以建一个那样的分支，但是分支是不能取代TAG的。
这里是不是还要介绍一下，如果master修改了，你的branch怎么update。
一般是这样的：
git checkout master // 切换到master branch
git pull //
git checkout your-branch
git pull . master // update your-branch
--
Yao Qi <qiyaoltc AT gmail DOT com>
Your depth of comprehension may tend to make you lax in worldly ways.
Other related posts:
