forked from git/git-reference
-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathindex-es.html
More file actions
166 lines (151 loc) · 8.05 KB
/
index-es.html
File metadata and controls
166 lines (151 loc) · 8.05 KB
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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
---
layout: reference
---
<div class="box">
<h2>Introducción a Referencia de Git </h2>
<!-- <h2>Introduction to the Git Reference</h2> -->
<div class="block">
<p>
Este es el sitio de referencia de Git. Esto pretende ser una
rápida referencia para aprender y recordar los comandos de
Git más importantes y frecuentes. Los comandos están organizados
en secciones según el tipo de operación que puedas estar
intentado realizar, y presentará las opciones y comandos frecuentes
necesarios para lograr esas tareas frecuentes.
<!-- This is the Git reference site. This is meant to be a quick
reference for learning and remembering the most important and
commonly used Git commands. The commands are organized into
sections of the type of operation you may be trying to do, and
will present the common options and commands needed to accomplish
these common tasks. -->
</p>
<p>
Cada sección enlazará a la siguiente sección, por lo que puede
usarse como un tutorial. Cada página también enlazará a documentación
más exhaustiva como páginas del manual oficial y secciones
relevantes del <a href="http://progit.org">libro Pro Git</a>,
para que puedas aprender más de cualquier comando. Primero,
empezaremos con pensar acerca de la gestión del código fuente
como Git lo hace.
<!-- Each section will link to the next section, so it can be used
as a tutorial. Every page will also link to more in-depth
Git documentation such as the offical manual pages and relevant
sections in the <a href="http://progit.org">Pro Git book</a>,
so you can learn more about any of
the commands. First, we'll start with thinking about source code
management like Git does. -->
</p>
</div>
</div>
<div class="box">
<h2>Cómo pensar como Git</h2>
<!-- <h2>How to Think Like Git</h2> -->
<div class="block">
<p>
La primera cosa que es importante entender acerca de Git es que
piensa acerca del control de versiones de manera muy diferente
a Subversion o Perforce o cualquier SCM al que puedas estar habituado.
Es usualmente más fácil aprender Git intentando olvidar tus
suposiciones acerca de cómo el control de versiones funciona e intentar
pensar acerca de ello a la manera de Git.
<!-- This first thing that is important to understand about Git is
that it thinks about version control very differently than
Subversion or Perforce or whatever SCM you may be used to. It
is often easier to learn Git by trying to forget your assumptions
about how version control works and try to think about it in the
Git way. -->
</p>
<p>
Empecemos desde cero. Supón que estás diseñando un nuevo sistema de
gestión de código fuente. ¿Cómo harías un control de versiones básico
antes de haber usado una herramienta para ello? Lo más probable es que
simplemente copiases el directorio de tu proyecto para guardar cómo
se ve en ese momento.
<!-- Let's start from scratch. Assume you are designing a new source
code management system. How did you do basic version control before
you used a tool for it? Chances are that you simply copied your
project directory to save what it looked like at that point. -->
</p>
<pre> $ cp -R project project.bak </pre>
<p>
De esta forma, puedes fácilmente revertir ficheros que puedan haberse
estropeado más tarde, o ver qué has cambiado comparando cómo se ve el
proyecto ahora a cómo se veía cuando lo copiaste.
<!-- That way, you can easily revert files that get messed up later, or
see what you have changed by comparing what the project looks like
now to what it looked like when you copied it. -->
</p>
<p>
Si eres realmente paranoico, harás esto a menudo, puede que insertando
la fecha en el nombre de la copia de seguridad.
<!-- If you are really paranoid, you may do this often, maybe putting the
date in the name of the backup: -->
</p>
<pre> $ cp -R project project.2010-06-01.bak </pre>
<p>
In ese caso, puedes tener un montón de instantáneas de tu proyecto desde
las que comparar e inspeccionar. Puedes incluso usar este modelo para
compartir efectivamente cambios con alguien. Si comprimes tu proyecto
en un estado conocido y lo pones en tu sitio web, otros desarrolladores
puede descargarlo, cambiarlo y enviarte un parche fácilmente.
<!-- In that case, you may have a bunch of snapshots of your project that
you can compare and inspect from. You can even use this model to
fairly effectively share changes with someone. If you zip up your
project at a known state and put it on your website, other developers
can download that, change it and send you a patch pretty easily. -->
</p>
<pre>
$ wget http://sample.com/project.2010-06-01.zip
$ unzip project.2010-06-01.zip
$ cp -R project.2010-06-01 project-my-copy
$ cd project-my-copy
$ (change something)
$ diff project-my-copy project.2010-06-01 > change.patch
$ (email change.patch)</pre>
<p>
Ahora el desarrollador original puede aplicar ese parche a su copia del
proyecto y tener los cambios. Así es cómo muchos proyectos de código libre
han estado colaborando durante varios años.
<!-- Now the original developer can apply that patch to their copy of the
project and they have your changes. This is how many open source
projects have been collaborated on for several years. -->
</p>
<p>
En realidad, esto funciona bastante bien, así que digamos que queremos
escribir una herramienta para hacer este proceso básico más rápido y
sencillo. En lugar de escribir una herramienta que versione cada fichero
individualmente, como Subversion, probablemente escribiríamos uno que haga
más sencillo almacenar instantáneas de nuestro proyecto sin tener
que copiar el proyecto entero cada vez.
<!-- This actually works fairly well, so let's say we want to write a tool
to make this basic process faster and easier. Instead of writing a tool
that versions each file individually, like Subversion, we would probably
write one that makes it easier to store snapshots of our project without
having to copy the whole directory each time. -->
</p>
<p>
Esto es ensencialmente lo que hace Git. Puedes decirle a Git que tu quieres
guardar una instantánea de tu proyecto con el comando <code>git commit</code>
y eso básicamente registra un manifiesto de cómo se ve tu proyecto en ese
punto. Entonces la mayoría de los comandos trabajan con esos manifiestos para
ver cómo difieren o extraer contenido de ellos, etc.
<!-- This is essentially what Git is. You tell Git you want to save a snapshot
of your project with the <code>git commit</code> command and it basically
records a manifest of what all of the files in your project look like at
that point. Then most of the commands work with those manifests to see
how they differ or pull content out of them, etc. -->
</p>
<center><img src="./images/snapshots.png"/></center>
<p>
Si piensas acerca de Git como una herramienta para almacenar y comparar y
unir instantáneas de tu proyecto, puede ser más sencillo para entender qué
es lo que está pasando y cómo hacer las cosas adecuadamente.
<!-- If you think about Git
as a tool for storing and comparing and merging snapshots of your project,
it may be easier to understand what is going on and how to do things
properly. -->
</p>
</div>
</div>
<p><a href="/creating">Ir a Obtención y Creación de proyectos »</a></p>
<!-- <p><a href="/creating">On to Getting and Creating Projects »</a></p> -->