Trabajando con git

Esta página recoge diversos conocimientos sobre el trabajo con el Repositorio Git de PostgreSQL. Tambien hay Otros repositorios Git.

En primer lugar, me gustaría sugerir la impresión de una copia de Trabajando con CVS, y no leerla; quémela, es un gran gesto simbólico.

Primeros pasos

Una manera sencilla de empezar puede parecerse a esto:

 git clone git://git.postgresql.org/git/postgresql.git
 cd postgresql
 git checkout -b my-cool-feature
 $EDITOR
 git diff master my-cool-feature | filterdiff --format=context > ../my-cool-feature.patch

Note that git checkout -b my-cool-feature creates a new branch and checks it out at the same time. Typically, you would develop each feature in a separate branch.

See the documentation and tutorials at http://git.or.cz/ for a more detailed Git introduction.

PostgreSQL developers have traditionally preferred context diffs (diff -c) over unified diffs (diff -u). At least some major committers who you will probably have to run your patch by heavily prefer context diffs. Bizarrely, Git doesn't easily produce context diffs. Some claims in old versions of the git-diff-files man page that you can use the environment variable GIT_DIFF_OPTS to control this are wrong and have been removed in later versions.

The best solution we have so far is using filterdiff as in the above example. If you can't find patchutils, of which filterdiff is one, packaged for your operating system, get it from the patchutils project.

Publicar su Trabajo

If you develop a feature over a longer period of time, you want to allow for intermediate review. The traditional approach to that has been emailing huge patches around. The more advanced approach that we want to try (see also Peter Eisentraut's blog entry) is that you push you Git branches to a private (~user) area on git.postgresql.org, where others can pull your work, operate on it using the familiar Git tools, and perhaps even send you improvements as Git-formatted patches. Please write to mailto:gitadmin@git.postgresql.org to get an account.

Si usted desarrolla una característica durante un período más largo de tiempo, es desea para permitir la revisión intermedia. El enfoque tradicional a la que ha sido enorme correo electrónico en torno a los parches. El enfoque más avanzado que queremos tratar (véase también la entrada al blog de Peter Eisentraut ) es que te empuje Git ramas a una empresa privada (~ usuario) en la zona git.postgresql.org, donde otros puedan tirar su trabajo, que operan en el uso la familiar Git herramientas, y quizás incluso enviarle mejoras como formato parches Git . Por favor, escriba a: mailto: gitadmin@git.postgresql.org para obtener una cuenta.

Eliminar una Rama

Una vez que su característica se ha comprometido al CVS de PostgreSQL, por lo general puede eliminar su rama local. Esto se hace de la siguiente manera:

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

Usar la Interfaz Web

Try the web interface at http://git.postgresql.org/. It offers browsing, "blame" functionality, snapshots, and other advanced features, and it is much faster than CVSweb. Even if you don't care for Git or version control systems, you will probably enjoy the web interface.

RSS Feeds

The Git service provides RSS feeds that report about commits to the repositories. Some people may find this to be an alternative to subscribing to the pgsql-committers mailing list. The URL for the RSS feed from the PostgreSQL repository is http://git.postgresql.org/?p=postgresql.git;a=rss. Other options are available; they can be found via the home page of the web interface.