<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="version-control" xml:lang="es">

  <info>

    <link type="guide" xref="index#general-guidelines"/>

    <credit type="author copyright">

      <name>Philip Withnall</name>

      <email its:translate="no">philip.withnall@collabora.co.uk</email>

      <years>2015</years>

    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>Control de versiones de código con git</desc>

    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">

      <mal:name>Daniel Mustieles</mal:name>

      <mal:email>daniel.mustieles@gmail.com</mal:email>

      <mal:years>2016</mal:years>

    </mal:credit>

    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">

      <mal:name>Javier Mazorra</mal:name>

      <mal:email>mazi.debian@gmail.com</mal:email>

      <mal:years>2016</mal:years>

    </mal:credit>

  </info>

  <title>Control de versiones</title>

  <synopsis>

    <title>Resumen</title>

      git is used for version control for all GNOME projects. This page assumes

      good working knowledge of git; some introductory material is available

      <link href="https://www.atlassian.com/git/tutorials/">here</link>, and a

      <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">git

      cheatsheet is here</link>.

    <list>

      <item>
Haga commits atómicos y reversibles. (<link xref="#guidelines-for-making-commits"/>)
</item>

      <item>
Incluya un razonamiento completo en los mensajes de commit, así como enlaces a los informes de error o a la especificaciones. (Consulte la <link xref="#guidelines-for-making-commits"/>)
</item>

      <item>
Haga los cambios grandes, como los renombrados, en commits separados. (Consulte la <link xref="#guidelines-for-making-commits"/>)
</item>

      <item>

        Merge changes from feature branches by rebasing.

        (<link xref="#use-of-git"/>)

      
</item>

    </list>

  </synopsis>

  <section id="use-of-git">

    <title>Uso de Git</title>

    
La mayoría de los repositorios de GNOME siguen estas reglas:

    <list>

      <item>

        No forced pushes. Except for branches with the wip/ prefix

        (work-in-progress), the commits’ history must not be modified, as

        contributors rely on it.

      
</item>

      <item>
Rebase los commits en lugar de mezclarlos, para tener un histórico lineal (más fácil de seguir).
</item>

      <item>

        Work on feature branches on GNOME git in wip/ branches,

        then rebase on master and fast-forward merge the changes. It is a good

        practice to also add your nickname to the branch name, as

        wip/nickname/feature.

      
</item>

      <item>

        Hide <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">sausage

        making</link> by squashing commits before merging.

      
</item>

    </list>

  </section>

  <section id="guidelines-for-making-commits">

    <title>Guía para realizar commits</title>

      Commits should be as small as possible, but no smaller. Each commit should

      address a single issue, containing only changes related to that issue. The

      message for each commit should describe the issue, explain what causes it,

      and explain how it has been fixed if it is not obvious. If the commit is

      associated with a bug report, the full URI for the bug report should be

      put on a line by itself at the bottom of the commit message. Similarly,

      the ID for the git commit (from <cmd>git log --oneline</cmd>) should

      be copied into the bug report once the commit has been pushed, so it is

      easy to find one from the other.

      The changes in each commit should be easy to read. For example, they

      should not unnecessarily change whitespace or indentation. Large,

      mechanical changes, such as renaming a file or function, should be put in

      separate commits from modifications to code inside that file or function,

      so that the latter changes do not get buried and lost in the former.

      The following principles give the reasoning for all the advice above:

    <list>

      <item>

        Each commit should take the repository from one working state to

        another, otherwise

        <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">bisection</link>

        is impossible.

      
</item>

      <item>

        Each commit should be individually revertable. If it later turns out

        that the commit was a bad idea,

        <cmd>git revert commit ID</cmd> should take the repository

        from a working state to another working state.

      
</item>

      <item>

        The reasoning for each commit, and its relationship to external

        resources like specifications and bug reports, should be clear, to the

        extent that commits written by one developer a year in the past should

        still be understandable by a second developer without having to trace

        through the changes and work out what they do.

      
</item>

      <item>

        Each commit should be written once, and designed to be read many times,

        by many reviewers and future programmers.

      
</item>

    </list>

  </section>

  <section id="merging-procedure">

    <title>Merging Procedure</title>

      To merge a feature branch named my-branch into master, use

      the following commands:

git checkout master

git pull

git checkout wip/my-branch

git rebase --interactive master

# Ensure the rebase is successful; test the changes

git checkout master

git merge wip/my-branch

git push

# wip/my-branch can now be deleted

git push origin :wip/my-branch

git branch -D wip/my-branch

  </section>

  <section id="external-links">

    <title>Enlaces externos</title>

    <list>

      <item>
<link href="https://sethrobertson.github.io/GitBestPractices/">Buenas prácticas de Git</link>
</item>

      <item>
<link href="https://help.github.com/categories/using-git/">P+F de Git</link>
</item>

      <item>
<link href="https://www.atlassian.com/git/tutorials/">Tutorial de Atlassian sobre git</link>
</item>

      <item>
<link href="http://git-scm.com/docs/gittutorial">Tutorial oficial de git</link>
</item>

      <item>
<link href="https://try.github.io/">Tutorial interactivo de  git</link>
</item>

      <item>
<link href="http://www.git-tower.com/learn/">Tutorial de git-tower</link>
</item>

    </list>

  </section>

</page>