跳转到内容

ROSE 编译器框架/Git

来自维基教科书,开放世界中的开放书籍

ROSE 项目经历了多个源代码内容管理阶段,从 CVS 开始,然后是 Subversion,现在是 Git。

Git 由于其独特的功能成为官方的源代码版本控制软件,包括

  • 分布式源代码管理。开发人员可以拥有一个独立的本地仓库,在任何他们想要的地方进行工作,而无需连接到中央仓库。
  • 轻松合并。使用 Git 合并非常简单。
  • 备份。由于中央仓库的轻松克隆可以作为独立的仓库。我们不再担心丢失中央仓库。
  • 完整性。Git 使用的散列算法确保您获得放入仓库中的内容。

许多其他著名的软件项目也经历了类似从 Subversion 切换到 Git 的过程,包括

有关 Git 用户的更完整列表,请访问 https://git.wiki.kernel.org/index.php/GitProjects

总之,Git 是最先进的源代码管理工具。

用于 github.com 的 git 1.7.10 或更高版本

[编辑 | 编辑源代码]

github 要求 git 1.7.10 或更高版本,以避免 HTTPS 克隆错误,如 https://help.github.com/articles/https-cloning-errors 所述。

Ubuntu 10.04 的软件包仓库中包含 git 1.7.0.4。因此需要构建更高版本的 git。但您仍然需要旧版本的 git 来获取最新版本的 git。

 apt-get install git-core

现在您可以克隆最新的 git

 git clone https://github.com/git/git.git

安装从源文件构建 git 所需的所有先决条件软件包(假设您已经安装了 GNU 工具链,包括 GCC 编译器、make 等)。

 sudo apt-get install gettext zlib1g-dev asciidoc libcurl4-openssl-dev
 $ cd git  # enter the cloned git directory
 $ make configure ;# as yourself
 $ ./configure --prefix=/usr ;# as yourself
 $ make all doc ;# as yourself
 # make install install-doc install-html;# as root

从 Subversion 用户转换

[编辑 | 编辑源代码]

如果您来自集中式系统,您可能需要忘记一些您习惯的事情。

  • 例如,您通常不会从中央仓库签出分支,而是克隆整个仓库的副本供自己本地使用。
  • 此外,Git 不使用小的连续整数来标识版本,而是使用密码散列 (SHA1),虽然通常您只需要写下散列的前几个字符——足以唯一标识一个版本。
  • 最后,要习惯的最大事情是:所有 (!) 工作都在本地分支上完成——在 DSCM 世界中,没有直接在中央分支上工作或直接将您的工作检入中央分支这样的概念。

话虽如此,分布式版本控制是集中式版本控制的超集,一些项目(包括 ROSE)设置了中央仓库作为共享代码的策略选择。当开发人员在 ROSE 上工作时,他们通常会从这个中央位置克隆,当他们进行更改后,他们通常会将这些更改推送到同一个中央位置。

Git 规范

[编辑 | 编辑源代码]

名称和电子邮件

[编辑 | 编辑源代码]

在您提交本地更改之前,您必须确保已正确配置您的作者和电子邮件信息(在您的所有机器上)。拥有一个可识别且一致的姓名和电子邮件将使我们更容易评估您对我们项目的贡献。

指南

  • 姓名:您必须使用您在工作/业务中常用的正式姓名,而不是无法被同事、经理或赞助商轻松识别的昵称或别名。
  • 电子邮件:您必须使用您在工作中常用的电子邮件。它可以是您的公司电子邮件或您的个人电子邮件(Gmail),如果您确实在业务中常用该个人电子邮件。

要检查您的作者和电子邮件是否已正确配置

  $ git config user.name
  <your name>

  $ git config user.email
  <your email>

或者,您也可以只键入以下内容来列出您当前的所有 git 配置变量和值,包括姓名和电子邮件信息。

  $ git config -l


要设置您的姓名和电子邮件

  $ git config --global user.name "<Your Name>"
  $ git config --global user.email "<[email protected]>"

分支命名规范

[编辑 | 编辑源代码]

所有开发人员中央仓库分支都应使用以下模式命名

  • 登录名-目的-选项
    • NAME 通常是登录名或姓氏。
    • PURPOSE 是对该分支上执行的工作类型的单字描述,例如“bugfixes”。
    • OPTION 是有关您分支的 ROSE 机器人的信息。
      • -test 对分支的更改将自动测试
      • -rc 更改将被测试,如果通过则将合并到“master”分支(如 Subversion 中的“trunk”)。
  • 示例
    • “matzke-bugfixes-rc”分支由 Robb Matzke “拥有”(即,他通常是该分支的更改者),它可能只包含错误修复或微小的编辑,并且正在被自动测试并合并到主分支中,最终发布给公众。

提交消息

[编辑 | 编辑源代码]

拥有简洁准确的提交消息对于帮助代码审阅者完成工作非常重要。

提交消息示例,摘自 链接

(Binary Analysis) SMT solver statistics; documentation

* Replaced the SMT class-wide number-of-calls statistic with a
  more flexible and extensible design that also tracks the amount
  of I/O between ROSE and the SMT solver.  The new method tracks
  statistics on a per-solver basis as well as a class-wide basis, and
  allows the statistics to be reset at artibrary points by the user.

* More documentation for the new memory cell, memory state, and X86
  register state classes.
  • (必需) 摘要:提交消息的第一行是提交的一行摘要(<50 字)。以一个主题开头,用括号括起来,表示该提交所代表的项目、功能、错误修复等。
  • (可选)使用项目符号列表(使用星号,*)逐项详细说明提交

另请参阅 http://spheredev.org/wiki/Git_for_the_lazy#Writing_good_commit_messages

通过 git-push 在远程仓库上创建和删除分支。

这是其一般形式

$ git push <remote> <syntaxhighlight-ref>:<destination-ref>
  • 当您克隆仓库时,默认的<remote>称为“origin”
  • The<source-ref>是您本地仓库中的分支(从<remote>克隆)您想要创建或与<remote>
  • The<destination-ref>是您想要在<remote>

创建远程分支

[编辑 | 编辑源代码]

示例

$ git remote -v
origin	https://github.com/rose-compiler/rose.git (fetch)
origin	https://github.com/rose-compiler/rose.git (push)

$ git branch
* master

# Method 1
$ git push origin master:refs/heads/master

# Method 2 - The currently checked out branch (see git-branch) is also called the <tt>HEAD</tt>
$ git push origin HEAD:refs/heads/master

# Method 3 - Git is pretty smart -- if you only specify one name, it will use it as both
# the source and destination.
$ git push origin master

删除远程分支

[编辑 | 编辑源代码]

删除远程分支只需不指定任何内容作为<source-ref>. 要删除分支my-branch, 请使用以下命令:git-push命令

$ git push origin :refs/heads/my-branch

建议在推送工作之前对分支进行变基。 这样您的本地提交将被移动到最新 master 分支的头部,而不是与 master 分支的提交交织在一起。

git pull origin master
git rebase master

来自 http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html

变基有助于将提交切片并以您希望的方式排列,并将它们放置在您希望的位置。 您可以使用此命令实际重写历史记录,无论是重新排序提交、将它们压缩成更大的提交,还是完全忽略它们,只要您愿意。

这有什么用呢?

  • 最常见的用例之一是您一直在不同的分支上处理自己的功能/修复等。 与为每个被带回 master 分支的更改创建难看的合并提交不同,您可以创建一个大的提交,让变基处理将其附加。
  • 变基的另一个常见用途是从项目中拉取更改并使您自己的修改保持一致。 通常,通过进行合并,您最终会得到一个历史记录,其中提交在 upstream 和您自己的提交之间交织在一起。 进行变基可以防止这种情况,并使顺序保持更加合理的状态。

修改子模块

[编辑 | 编辑源代码]

ROSE 使用子模块链接到 EDG 文件。

默认签出的子模块版本位于一个幽灵分支上

  [youraccount@yourmachine:~/rose/src/frontend/CxxFrontend/EDG]git branch
  * (no branch)
    master

您必须在更改子模块之前创建一个本地分支,您应该基于幽灵分支创建一个新分支,该分支可能与远程 master 相对应,也可能不对应。 在我们的设置中,我们将 EDG 更改推送到非 master 分支,因此幽灵分支很可能与非 master 分支相关联。

$ git checkout -b fix-up

进行您更改后

始终先提交并推送子模块更改

  $ git commit -a -m "Updated the submodule from within the superproject."  // commit locally
  $ git push origin HEAD:refs/heads/your-account/edg4x-rc  // push to your own remote branch

最后更改超级项目的链接,使其指向已更改的子模块

  $ cd ..           # back down to its parent repository's path
  $ git add EDG  # Please note: NEVER use "git add EDG/"  !!!! , this will add all files under EDG/ to the super project!!
  $ git commit -m "Updated submodule EDG."
  $ git push

参考资料

[编辑 | 编辑源代码]
华夏公益教科书