forked from ComunidadBioInfo/cdsb2021_workflows
-
Notifications
You must be signed in to change notification settings - Fork 0
/
02_sesion4.Rmd
313 lines (223 loc) · 8.46 KB
/
02_sesion4.Rmd
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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
# Merge y conflictos de versiones en Git y GitHub
Alejandra Medina-Rivera
10 de agosto de 2021
## Diapositivas
[
```{r, echo=FALSE}
knitr::include_url("https://comunidadbioinfo.github.io/cdsb2021_workflows/GitConflict.html",
height = "380px")
```
](https://comunidadbioinfo.github.io/cdsb2021_workflows/GitConflict.html)
## Agradecimientos
- Este documento se basa en "Happy Git with R" de Jenny Bryan, los STAT 545 TAs, Jim Hester
https://happygitwithr.com
## Usando git de forma segura
- Usando commit podemos evitar problemas
- Cada commit es un pin de seguridad en una escalada
- Debemos hacer commit LOCAL continuamente
- LOCAL quiere decir sin PUSH
```{bash eval=FALSE, echo=TRUE}
git commit -m "Mensaje que diga que hice"
```
## Commit al infinito
- Hacer commit LOCAL es muy bueno pero puede dejar nuestra historia un poco intensa
- Para eso existe amend
- no-edit va a dejar el mensaje original del commit
```{bash eval=FALSE, echo=TRUE}
git commit -m "Mensaje que diga que hice"
git commit --amend --no-edit
```
- Cuando hayamos terminado de trabajar podemos cambiar el mensaje y dejar algo más completo
```{bash eval=FALSE, echo=TRUE}
git commit --amend --m "ahora que ya terminé puedo dejar algo más completo"
git push
```
## Viajando en el tiempo
- Estamos trabajando y nos equivocamos y ya nada sirve
- Podemos volver al último commit donde todo funcionaba!
```{bash eval=FALSE, echo=TRUE}
git reset --hard
```
## Reescribiendo la historia
- Amend es reescribir la historia de un commit.
- Es importante no reescribir historias si ya se hizo PUSH
- Cuando hacemos PUSH alguien de nuestro equipo podría ya haber hecho PULL.
- Si por algo ya hicimos PUSH tenemos dos opciones:
1. reset a un commit anterior y luego hacer pull
```{bash eval=FALSE, echo=TRUE}
git reset --hard HEAD
git pull
```
2. Si estamos super seguros que nadie de nuestro equipo hizo pull de nuestro error, entonces podemos hacer un push force
```{bash eval=FALSE, echo=TRUE}
git push --force
```
## Reescribiendo la historia
- Repetimos: De verdad no hay que hacer force
## Rechazo de PUSH
- Un problema común es que intentemos hacer PUSH a nuestro repositorio central y que se rechacen nuestros cambios
```{bash eval=FALSE, echo=TRUE}
$ git push
To https://github.com/YOU/REPO.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://github.com/YOU/REPO.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```
-Esto quiere decir que el repositorio central y lo que tenemos local han divergido.
## Rechazo de PUSH
-Solución: hacer PULL a local y lidiar con los conflictos
-Cómo evitar que estemos pasando por este tipo de situaciones:
1. No trabajar offline demasiado tiempo y hacer commit y PUSH seguido.
2. Hacer PULL de forma continua para evitar divergir. Así si algo divergió el merge será menos doloroso.
3. Trabajo en equipo, comunicación en equipo. Si sabemos qué hacen los demás es más fácil evitar conflictos.
4. Uso de branches, organizar el progreso de nuestro trabajo en equipo en branches hará menos doloroso hacer integración con otras versiones.
## Rechazo de PUSH > Hagamos PULL
- Inevitable: nos rechazan un PUSH así que debemos hacer PULL
- Nuestra historia local:
A--B--C
A--B-- Cambios sin commit
- La historia en el repositorio central:
A--B--D
- Lo que queremos es hacer una fusion
## PULL con cambios locales sin commit
-Escenario 1: PULL feliz
```{bash eval=FALSE, echo=TRUE}
git pull
```
- Cuando no hay sobrelape entre lo que cambió en el repo central y lo que hice local, entonces PULL simplemente va a funcionar, dejando nuestra nueva historia incluyendo C
A--B--C--(uncommitted changes)
## PULL con conflictos
- Si hay sobrelape entre lo que hicimos local y el repo central pull va a fallar
```{bash eval=FALSE, echo=TRUE}
$ git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:jennybc/ethel
db046b4..2d33a6f master -> origin/master
Updating db046b4..2d33a6f
error: Your local changes to the following files would be
overwritten by merge:
foo.R
Please commit your changes or stash them before you merge.
Aborting
```
- Quién me dice cuál es el problema?
## Solución con git stash
- stash nos permite guardar los cambios locales que no pasamos a commit en un universo medio paralelo
```{bash eval=FALSE, echo=TRUE}
$ git stash save
Saved working directory and index state WIP on master: db046b4
Merge branch 'master'of github.com:jennybc/ethel
$ git pull
Updating db046b4..2d33a6f
Fast-forward
foo.R | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git stash pop
Auto-merging foo.R
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes
in working directory)
modified: foo.R
no changes added to commit
```
## Cuando git stash no trae la felicidad
```{bash eval=FALSE, echo=TRUE}
git stash pop
Auto-merging foo.R
CONFLICT (content): Merge conflict in foo.R
```
## Merge conflics
- A veces, no tan a veces también, las cosas no salen bien a la primera
- Merging (Fusionar) es una de esas cosas
- Primera regla: NO ENTRAR EN PANICO!!!
- Revisen el status del repositorio. Qué archivo tiene conflicto?
## Merge conflics
- Abran ese archivo y busquen los problemas de merge. Es fácil, se ven así:
```{r echo=TRUE, eval=FALSE}
<<<<<<< HEAD:index.html
<div id="footer">contact : [email protected]</div>
=======
<div id="footer">
please contact us at [email protected]
</div>
>>>>>>> issue-5:index.html
```
- Editen esa sección, dejen una versión final.
## Regresando a git stash
- Ya tenemos la versión final de nuestro archivo conflictivo
- Ahora a limpiar un poco el desastre
```{bash eval=FALSE, echo=TRUE}
$ git reset
$ git reset --mixed
Unstaged changes after reset:
M foo.R
```
- git reset (default: mixed) nos va a regresar al "commit" anterior.
- PELIGRO: la opción hard de git reset incluso borra todo lo que pasó después del commit. Esto es como rm -f, así que con cuidado!
## Regresando a git stash
- Por último, debemos dejar el stash que estábamos haciendo
```{bash eval=FALSE, echo=TRUE}
$ git stash drop
Dropped refs/stash@{0} (7928db50288e9b4d934803b6b451a000fd7242ed)
```
- Ya quedó todo listo para continuar
## Qué hacemos si si hicimos commit y PULL no funciona?
- PULL, fetch/merge
-El mejor escenario es que el merge es fácil por que no hay conflictos
```{bash eval=FALSE, echo=TRUE}
$ git pull
<Se habre un editor de texto para que podamos añadir
un mensaje al Merge>
Merge made by the 'recursive' strategy.
README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
```
## Qué hacemos si si hicimos commit y PULL no funciona?
- El escenario donde falla el merge
```{bash eval=FALSE, echo=TRUE}
$ git pull
Auto-merging foo.R
CONFLICT (content): Merge conflict in foo.R
Automatic merge failed; fix conflicts and then commit the result.
```
- Arreglamos todo como la vez pasada, eligiendo en el archivo la versión que nos gusta y cuando estemos listos add y commit
```{bash eval=FALSE, echo=TRUE}
$ git add foo.R
$ git commit
```
## PULL con rebase
- Pull combinado con su opción rebase hace una historia más limpia.
- Nos evitamos añadir otro commit consecuencia del merge
- Es tentador pero peligroso por que los cambios locales se aplicarán sobre los remotos
## PULL con rebase
```{bash eval=FALSE, echo=TRUE}
$ git pull --rebase
First, rewinding head to replay your work on top of it...
Applying: Take max
```
- El problema: vamos a acarrear conflictos de merge en el futuro y nuestra historia se reescribe un poco
```{bash eval=FALSE, echo=TRUE}
$ git rebase --abort
```
## Actividad
### Probemos nosotres!
- Vayan a GitHub y creen en repostorio "toxico"
- Creen un README
- Clonen este reposotorio a sus computadoras
- Editen el README en su computadora
- Ahora editen el READM en el GitHub
- Traten de hacer pull, qué pasó?
- Cómo lo arreglamos?
### Todo es práctica
Y si nada funciona pues volvemos a instalar el repo