1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
<?xml version="1.0" encoding="utf-8"?>
<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-2020</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, 2020</mal:years>
</mal:credit>
</info>
<title>Control de versiones</title>
<synopsis>
<title>Resumen</title>
<p>git se utiliza como control de versiones para todos los proyecto de GNOME. Esta página asume un buen conocimiento de trabajo con git; algunos materiales introductorios están disponibles<link href="https://www.atlassian.com/git/tutorials/">aquí</link>, y <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">aquí hay una chuleta de git</link>.</p>
<list>
<item><p>Haga commits atómicos y reversibles. (<link xref="#guidelines-for-making-commits"/>)</p></item>
<item><p>Incluya un razonamiento completo en los mensajes de commit, así como enlaces a los informes de error o a la especificaciones. (Consulte la sección <link xref="#guidelines-for-making-commits"/>)</p></item>
<item><p>Haga los cambios grandes, como los renombrados, en commits separados. (Consulte la sección <link xref="#guidelines-for-making-commits"/>)</p></item>
<item><p>Fusione los cambios de las ramas de características haciendo rebase. (<link xref="#use-of-git"/>)</p></item>
</list>
</synopsis>
<section id="use-of-git">
<title>Uso de Git</title>
<p>La mayoría de los repositorios de GNOME siguen estas reglas:</p>
<list>
<item><p>No fuerce los envíos. Excepto para las rama con el prefijo <code>wip</code> (work-in-progress), el historial de commit no debe modificarse, ya que los colaboradores confían en él.</p></item>
<item><p>Rebase los commits en lugar de mezclarlos, para tener un histórico lineal (más fácil de seguir).</p></item>
<item><p>Trabaje en ramas de características en GNOME git en ramas <code>git</code>, después haga rebase en master y fusione rápidamente los cambios. Es una buena práctica añadir también su apodo al nombre de la rama, como <code>wip/apodo/feature</code>.</p></item>
<item><p>Ocultar <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">elaboración de salchichas</link> juntando los commits antes de fusionarlos.</p></item>
</list>
</section>
<section id="guidelines-for-making-commits">
<title>Guía para realizar commits</title>
<p>Los commits deben ser tan pequeños como sea posible, pero no más pequeños. Cada commit debe abordar un único problema, conteniendo solo cambios relacionados con ese problema. El mensaje para cada commit debe describir el problema, explicar qué lo causa y explicar cómo se ha corregido si no es obvio. Si el commit está asociado con un informe de error la URI completa del informe de error debe ponerse en una línea separada en la parte inferior del mensaje del commit. De la misma forma, el ID para el git commit (de <cmd>git log —oneline</cmd>) debe copiarse en el informe de error una vez se haya enviado el commit, para que sea fácil encontrar uno desde el otro.</p>
<p>Los cambios en cada commit deben ser fáciles de leer. Por ejemplo, no deben cambiar innecesariamente el espacio en blanco o la sangría. Los cambios mecánicos grandes, como el renombrado de un archivo o una función, deben ponerse en commits separados de las modificaciones en el código dentro de ese archivo o función, para que los últimos cambios no queden enterrados y se pierdan en el primero.</p>
<p>Los siguientes principios dan el razonamiento para todos los consejos anteriores:</p>
<list>
<item><p>Cada commit debe llevar el repositorio de un estado de trabajo a otro, de lo contrario la <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">búsqueda binaria</link> es imposible.</p></item>
<item><p>Cada commit debe ser reversible individualmente. Si después resulta que el commit fue una mala idea, <cmd>git revert <var>commit ID</var></cmd> debe llevar el repositorio de un estado de trabajo a otro estado de trabajo.</p></item>
<item><p>El razonamiento de cada commit y su relación con recursos externos, como especificaciones e informe de errores, deben ser claros, de manera que esos commits escritos por un desarrollador un año atrás aún deben ser comprensibles por un segundo desarrollador sin tener que rastrear los cambios y averiguar lo que hacen.</p></item>
<item><p>Cada commit debe escribirse una vez y diseñarse para ser leído muchas veces por muchos revisores y futuros programadores.</p></item>
</list>
</section>
<section id="merging-procedure">
<title>Procedimiento de fusión</title>
<p>Para fusionar una rama de característica llamada <code>my-branch</code> en master, utilice los siguientes comandos:</p>
<code mime="application/x-shellscript">
git checkout master
git pull
git checkout wip/<var>my-branch</var>
git rebase --interactive master
# Ensure the rebase is successful; test the changes
git checkout master
git merge wip/<var>my-branch</var>
git push
# wip/<var>my-branch</var> can now be deleted
git push origin :wip/<var>my-branch</var>
git branch -D wip/<var>my-branch</var></code>
</section>
<section id="external-links">
<title>Enlaces externos</title>
<list>
<item><p><link href="https://sethrobertson.github.io/GitBestPractices/">Buenas prácticas de Git</link></p></item>
<item><p><link href="https://help.github.com/categories/using-git/">P+F de Git</link></p></item>
<item><p><link href="https://www.atlassian.com/git/tutorials/">Tutorial de Atlassian sobre git</link></p></item>
<item><p><link href="http://git-scm.com/docs/gittutorial">Tutorial oficial de git</link></p></item>
<item><p><link href="https://try.github.io/">Tutorial interactivo de git</link></p></item>
<item><p><link href="http://www.git-tower.com/learn/">Tutorial de git-tower</link></p></item>
</list>
</section>
</page>
|
