使用 Git

来自 PostgreSQL 维基
跳转到导航跳转到搜索

此页面收集了关于使用 PostgreSQL Git 仓库 的各种经验。你可能还会使用 其他 Git 仓库，最值得注意的是官方的 Github 镜像，你可以在该网站上 fork 它。

入门

一个简单的入门方法可能如下所示

git clone https://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b my-cool-feature
$EDITOR
git commit -a
git diff --patience master my-cool-feature > ../my-cool-feature.patch

注意 git checkout -b my-cool-feature 会同时创建一个新分支并检出它。通常，你应该在不同的分支上开发每个功能。

查看 https://git.js.cn/doc/ext 上的文档和教程，以获得更详细的 Git 介绍。要获得更深入的课程，请查看 Pro Git 书籍，并可能获取纸质版以帮助支持该网站。

你可能希望将以下内容放在你的 .git/info/exclude GitExclude 中。现在主仓库已经转换为 git，标准的 .gitignore 文件应该涵盖所有构建产物，所以你不需要在该参考中列出的大多数内容。你可能仍然希望排除 *~、标签和 /cscope.out，尽管如此。

保持本地主分支同步

首先，将 origin 添加为远程仓库。你只需要做一次

git remote add origin https://git.postgresql.org/git/postgresql.git

接下来，从你的公共 git 仓库中获取

git fetch origin master

合并来自你的公共仓库的任何新补丁

git merge FETCH_HEAD

合并来自主分支的任何更改

git fetch origin master
git merge FETCH_HEAD

现在检查它是否仍然可以编译，通过回归测试等。确保你已经调用了 ./configure，然后

make check
make maintainer-clean

假设所有这些都很好，进行一次试运行。

git push --dry-run origin master

如果一切顺利，就将其推送到你的公共仓库。

git push origin master

如果不是，修复任何合并错误，进行另一次试运行，然后推送。

跟踪其他分支

假设你乐于跟踪主分支，但你真的想跟踪 git.postgresql.org 上任何一个潜在的分支

git remote add <super-fun-branch> https://git.postgresql.org/super-fun-branch.git
git fetch super-fun-branch
git checkout super-fun-branch #this will stage your remote branch for a local checkout
git checkout -b super-fun-branch-name #the name can be wahtever you choose

现在你在你的本地 git 仓库中有一个本地分支跟踪另一个分支的历史记录。最重要的是，如果你需要，你就可以推送该仓库，而无需明确克隆以跟踪历史记录。与主分支共享一些共同历史记录几乎是不可能的。

使用旧分支

由于 git 仓库包含 PostgreSQL 每个主要版本的各个分支，因此很容易使用旧版本的最新代码而不是当前版本。以下是如何列出可能性并检出旧版本

 git branch -r
 git checkout -b REL_15_STABLE origin/REL_15_STABLE

请注意，如果你已经检出并使用了更高版本，你可能需要清理它留下的部分文件。建议运行

 make maintainer-clean

尽可能地清除它们。你可能需要在 git 允许你执行检出之前删除一些遗留的文件（对于上面的特定示例，src/interfaces/ecpg/preproc/preproc.y 可能是一个问题）。

测试补丁

这是一个典型的设置，用于查看补丁文本文件，通常是通过电子邮件发送的

git checkout -b feature-to-review
patch -p1 < feature.patch

如果补丁无法应用，就会留下 file.rej 文件，显示未应用的部分。如果你的目录树中没有构建信息，你可以很容易地使用以下方法找到它们

git status

补丁清理

补丁差异提交效果最好是作者对实际补丁进行一轮自我审查——不仅仅是代码，还有生成的物理差异文件。 创建干净的补丁 涵盖了通常用于生成更好的补丁差异输出的做法。

发布你的工作

如果你在较长时间内开发一个功能，你希望允许进行中间审查。传统的做法是将大型补丁通过电子邮件发送。我们想要尝试的更高级的方法（参见 Peter Eisentraut 的 博客条目）是，你将你的 Git 分支推送到 git.postgresql.org 上的私有区域，其他人可以在那里拉取你的工作，使用熟悉的 Git 工具操作它，甚至可以将改进以 Git 格式的补丁形式发送给你。查看 git.postgresql.org 网站，了解如何注册以及如何使用仓库。你可能最终需要通过电子邮件创建补丁，作为正式 提交补丁 的一部分。

推送新分支

如果你创建了一个新分支，通常用于新的功能测试，你需要将其推送到 git.postgresql.org。

 git push origin new_feature_branch

注意，如果你有一个完全空白的仓库，那么甚至 "master" 分支也不存在，需要推送。

如果你在使用 postgresql 核心代码，请不要随意创建自己的分支并推送它们，而没有先在 pgsql-hackers 列表上清理。通常，你应该使用你的私有仓库区域。

删除分支

一旦你的功能被提交到 PostgreSQL 仓库，你通常可以删除你的本地功能分支。操作方法如下

# switch to a different branch
git checkout master
git branch -D my-cool-feature

使用 git hooks

Git hooks 是在发生某些事件（例如提交或推送）时运行的脚本。它们放置在你的 .git/hooks 目录中。这是一个示例脚本，用于检查你在提交代码时代码是否已正确缩进，并可以选择为你重新缩进它（通过将 PGAUTOINDENT 环境变量设置为 yes）。要使用它，请将其放在 .git/hooks/pre-commit 中，并使用 chmod +x .git/hooks/pre-commit 使其可执行

#!/bin/sh
set -u
: ${PGAUTOINDENT:=no}

# the files in the commit
if git diff --cached --name-only --diff-filter=ACMR | grep src/tools/pgindent/typedefs.list > /dev/null; then
    # if typedefs.list is changed, we need to re-run pgindent on all files
    files='src contrib'
else
    files=$(git diff --cached --name-only --diff-filter=ACMR)
fi

check_indent () {
  # no need to filter files - pgindent ignores everything that isn't a
  # .c or .h file

  if [ "$PGAUTOINDENT" = yes ] ; then
    TEMPFILE=$(mktemp)
    trap "rm $TEMPFILE" EXIT
    if ! src/tools/pgindent/pgindent --check --diff $files > $TEMPFILE; then
      patch -p0 < $TEMPFILE
      echo "Commit abandoned. Rerun git add+commit to adopt pgindent changes"
      exit 1
    fi
  elif ! src/tools/pgindent/pgindent --check $files; then
    echo 'You need a pgindent run, e.g:'
    echo -n 'src/tools/pgindent/pgindent '
    if [ $files = 'src contrib' ]; then
        echo $files
    else
        echo '$(git diff --name-only --diff-filter=ACMR)'
    fi
    exit 1
  fi
  
}

# nothing to do if there are no files
test -z "$files" && exit 0
check_indent

使用 users/foo/postgres.git

在 git.postgresql.org 上请求项目时，一个选项是拥有主 postgresql 仓库的克隆。

这是一个非常好的功能，但是如何同步上游代码呢？

一种方法是在你自己的仓库中创建一个 git 克隆，并添加一个新的远程仓库来处理同步

# clone your repos
git clone ssh://[email protected]/users/foo/postgres.git my_postgres

# add a new remote
git remote add pgmaster https://git.postgresql.org/git/postgresql.git

# track some old versions
git checkout -b REL8_3_STABLE origin/REL8_3_STABLE
git checkout -b REL8_4_STABLE origin/REL8_4_STABLE

# change the remote of master and our old versions tracked
git config branch.REL8_3_STABLE.remote pgmaster
git config branch.REL8_4_STABLE.remote pgmaster
git config branch.master.remote pgmaster

# pull from postgres official git for each branch
# and finally push to origin
git checkout master
git pull
git push origin
git checkout REL8_3_STABLE
git pull
git push origin
git checkout REL8_4_STABLE
git pull
git push origin


这样，PostgreSQL 就很容易为每个分支同步。从官方仓库拉取并推送到你自己的仓库。

创建你自己的分支并像往常一样工作。拥有 postgresql.git 本地克隆的用户可以在他们的仓库中添加你的分支，并且可以愉快地合并，就像你一样。

使用 Web 界面

尝试 https://git.postgresql.org/ 上的 Web 界面。它提供浏览、"blame" 功能、快照和其他高级功能，并且比 CVSweb 快得多。即使你不关心 Git 或版本控制系统，你也会喜欢这个 Web 界面。

RSS 订阅

Git 服务提供 RSS 订阅，用于报告对仓库的提交。有些人可能会发现这是一种替代订阅 pgsql-committers 邮件列表的方法。PostgreSQL 仓库的 RSS 订阅 URL 是 https://git.postgresql.org/gitweb/?p=postgresql.git;a=rss。还提供其他选项；它们可以在 Web 界面的 主页 上找到。

PostgreSQL 风格

PostgreSQL 源代码使用 4 个字符的制表符，这使得 git diff 的输出看起来很奇怪。你可以通过将以下内容放在你的 .git/config 文件中来解决此问题

 [core]
   pager = less -x4

继续 "rsync the CVSROOT" 工作流

Aidan van Dyk 发布了一个很棒的教程，介绍如何使用历史对象的单个副本保留多个分支。这大致等同于保留 rsync'ed 的 CVSROOT 副本的多个检出，这正是某些提交者使用 CVS 时所做的事情。

检索自 "https://wiki.postgresql.ac.cn/index.php?title=Working_with_Git&oldid=38541"