-
Notifications
You must be signed in to change notification settings - Fork 13
/
Git.txt
executable file
·1522 lines (1006 loc) · 46.3 KB
/
Git.txt
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
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
==========================
Guía de Git y GitHub by dM
==========================
Software de control de versiones diseñado por Linus Torvalds, pensando en la
eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones
cuando éstas tienen un gran número de archivos de código fuente. Hay algunos
proyectos de mucha relevancia que ya usan Git en particular, el grupo de
programación del núcleo Linux.
Nota:
-Usaremos $ para describir los comandos que se usaran con usuario regular.
-Usaremos # para describir los comandos que se usaran con superusuario.
-----
Instalar Git
# apt install git
-----
Con este comando nos listara la lista de comandos Git que podemos usar en un
proyecto.
$ git
-----
Saber que versión tenemos instalada.
$ git --version
-----
Lo primero que debemos hacer despues de la instalacion es configurar nuestro
Git.
Asignamos el nombre de usuario que será la firma del usuario en cada commit.
$ git config --global user.name "Argenis Osorio"
Igualmente el correo que siempre acompañara al autor de cada commit.
$ git config --global user.email aosorio@example.com
Comprobar el valor de las variables de configuración inicial de git, las que
acabamos de introducir.
$ git config --list
-----
Crear un directorio, dentro del directorio ejecutar para crear un nuevo
repositorio de git, nos crea una carpeta .git.
$ git init
Dentro están todos los ficheros de configuración de git para ese repositorio
específico.
-----
Remover git del directorio de trabajo.
$ rm -rf .git
-----
Muestra el estado actual de la rama, como los cambios que hay sin commitear.
$ git status
Lista los archivos del proyecto y se visualiza si fueron agregados al
seguimiento de Git.
-----
Tambien podemos ver si un archivo fue modificado y no ha sido agregado al
seguimiento de Git.
$ git status -s
-----
Agregar todos los archivos al seguimiento de Git.
$ git add *
-----
Hacer un commit al proyecto, se activara la rama master por defecto.
$ git commit -m "Primer commit del proyecto"
-----
Podemos ver todos los commits que se han hecho a un proyecto, fecha,
autor, etc...
$ git log
-----
Ver los autores de los commits además de listar cuantos commits han realizado.
$ git shortlog
-----
Genera un resumen condensado de información extendida del encabezado, como
creaciones o eliminaciones de archivos ("nuevo" o "desaparecido", opcionalmente
"+ l" si es un enlace simbólico) y cambios de modo ("+ x" o "-x" para agregar o
eliminar bit ejecutable respectivamente) en diffstat. La información se coloca
entre la parte del nombre del archivo y la parte del gráfico. Implica --stat.
$ git log --compact-summary
-----
Muestra solo los nombres y el estado de los archivos modificados. Al igual que
--name-only, los nombres de los archivos a menudo se
codifican en UTF-8.
$ git log --name-status
-----
Lista todas las ramas locales.
$ git branch
-----
Lista todas las ramas locales y remotas.
$ git branch -a
-----
Lista todas las ramas locales y remotas.
$ git remote
-----
Lista todas las ramas, locales y remotas con más detalles como la url.
$ git remote -v
-----
Agregar un repositorio remoto a mi repo de Git.
$ git remote add my_name_remote https://github.com/darknesstrue/myrepo.git
-----
Push a la rama del repositorio remoto
$ git push <remote> <branch>
-----
Deshacer un git add antes de un commit
$ git reset <archivo>
$ git reset
-----
Ejemplo de archivos agregados al seguimiento de git:
A gris.jpg // Agregado
A file.html // Agregado
AM file2.html // Agregado y modificado, se debe agregar otra vez
?? file3.html // Archivo agregado al directorio pero no agregado al seguimiento
Agregar un fichero específico al seguimiento de Git, esto es útil si tenemos
muchos ficheros con modificaciones pero solo queremos subir los cambios de
algunos específicos, no de todos, entonces los agregamos manualmente.
$ git add Nombre_archivo.xxx
Ejemplo de varios archivos modificados, solo agregaremos algunos al seguimiento
de git:
modified: fichero1.xxx
modified: fichero2.xxx
modified: fichero3.xxx
modified: fichero4.xxx
modified: fichero4.xxx
Agregando ficheros específicos al seguimiento de git.
$ git add fichero1.xxx fichero2.xxx fichero3.xxx
El resto seguira esperando por una accion, como ser eliminado, seguir siendo
modificado o agregado al seguimiento.
-----
Borrar un fichero de manera segura, puesto que lo borra del directorio y del
seguimiento de git, es un error común borrar los archivos directamente y estos
siguen estando en el seguimiento de git por lo que se lia bastantes veces al
subir los cambios, recomendable borrarlos desde git.
$ git rm Nombre_fichero.xxx
-----
Forzar el borrado del fichero.
$ git rm -f Nombre_fichero.xxx
-----
Si un archivo fue modificado queda un registro de su nombre anterior en el cache
para borrarlo se usa este comando.
$ git rm --cached Nombre_archivo.xxx
-----
Para borrar un directorio y su contenido del seguimiento de git.
$ git rm --cached -r dir/dir
-----
Para borrar un directorio y su contenido del seguimiento de git, esta opción
funciona optimamente en mis pruebas.
$ git rm --cached -r dir/*
---
Corregir algun error en el texto del último commit
$ git commit --amend -m "comentario commit corregido"
Corregir un error en el commit, abrira un editor de texto
$ git commit --amend
---
Correguir un commit particular:
$ git rebase -i hash-del-commit~1
git rebase -i hash-del-commit~1 para pedir hacer rebase interactivo de la rama
actual a partir del commit anterior (~1) al que estás queriendo modificar. Eso
disparará tu editor por defecto con un listado de todos los commits que existen
desde ese hasta el tope de tu rama, indicando pick, hash y mensaje de cada uno.
Algo como:
pick abcdef0 Mensaje del commit más nuevo
pick bcdef01 Mensaje del commit anterior
pick fde2152 Mensaje del commit a editar
Cambiar pick por r o reword en la línea del commit a editar. ejemplo:
pick abcdef0 Mensaje del commit más nuevo
pick bcdef01 Mensaje del commit anterior
r fde2152 Mensaje del commit a editar
Guardar el fichero y salir, git va a volver hasta ese commit y abrirá el editor
nuevamente, pero esta vez con el mensaje del commit ahí presente. Algo como:
Mensaje del commit a editar
Este mensaje es el que habías escrito en el primer
git commit, y que ahora querés reemplazar por uno nuevo
Editar el mensaje para corregirlo, guardamos el archivo, salimos del editor, y
git aplicará todos los commits que faltaban para que tu rama quede igual,
excepto por tener el mensaje actualizado.
No olvidar que se está modificando la historia de tu repositorio, por lo que si
habías publicado el commit al que estás editando el mensaje o cualquiera de sus
sucesores podés generar conflictos.
---
Borrar el ultimo commit hecho.
$ git reset --hard HEAD~1
-----
Deshaciendo la preparación de un archivo, con esto le decimos a git que deje de
seguir a un archivo.
$ git reset HEAD name_file.xxx
-----
Crear una rama.
$ git branch Nombre_Rama
-----
Crear una rama y cambiarse a ella.
$ git checkout -b Nombre_Rama
-----
Borrar o eliminar una rama, se debe estar en otra rama para borrarla
$ git branch -d Nombre_Rama
-----
Forzar el borrado o eliminación de una rama, a veces no se dejan borrar si hay
cambios sin guardar.
$ git branch -D Nombre_Branch
-----
Borrar o eliminar una rama de un repositorio remoto.
$ git push origin :the_remote_branch
-----
Borrar o eliminar múltiples ramas según la busqueda filtrada.
Para borrar todas las ramas locales que comiencen con feat, puedes ejecutar el
siguiente comando en Git:
$ git branch | grep '^ feat' | xargs git branch -d
Explicación:
git branch: Lista todas las ramas locales.
grep '^ feat': Filtra las ramas que comienzan con feat. El ^ indica el comienzo
de la línea y el espacio en blanco que sigue está incluido para capturar ramas
que están alineadas correctamente en el listado.
xargs git branch -d: Pasa las ramas encontradas a git branch -d, que borra las
ramas locales.
Si algunas de estas ramas no se pueden eliminar porque aún no están
completamente fusionadas, puedes usar la opción -D en lugar de -d para forzar la
eliminación:
$ git branch | grep '^ feat' | xargs git branch -D
Fuente
======
ChatGPT
-----
Cambiarse de rama
$ git checkout Nombre_Rama
-----
Para ver los ultimos commits de cada rama.
$ git branch -v
-----
Subir los cambios al repositorio remoto en la rama master.
$ git push origin master
-----
Estando en otra rama local, Subir los cambios al repositorio remoto en la rama
master, si no existe la rama, la creará.
$ git push origin nombre_rama
git push -f <remote> <branch> forzar el push para sobreescribir los ficheros en
el repositorio remoto.
$ git push -f origin master
-----
Guardado rápido provisional de los cambios pendientes, lo cual nos va a permitir
cambiarnos de rama sin que se nos queje de que hay cambios pendientes.
$ git stash
-----
Listar los estados guardados provicionalmente.
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size"
stash@{2}: WIP on master: 21d80a5... added number to log
-----
Reactivando el primer cambio guardado rápídamente, falta probar bien.
$ git stash apply stash@{0}
-----
Es posible que no desee guardar algunos trabajos o archivos en su directorio de
trabajo, sino simplemente deshacerse de ellos; para eso es el comando:
$ git clean
==================================
Configurando el fichero .gitignore
==================================
Cuando creamos un repositorio git dentro de un directorio, inicialmente se
incluyen todos los archivos de dicho directorio dentro del control de versiones
de git, para así poder seguir los cambios que se van realizando en el proceso de
desarrollo.
Ficheros .gitignore, es en estos archivos donde se incluyen las rutas de todos
los directorios y ficheros que queremos excluir de git, es decir, que no
queremos que sean rastreados.
Básicamente git hace una lectura en todos los directorios dentro de la carpeta
del proyecto, y cada vez que encuentre un archivo .gitignore lo lee para saber
que otros archivos debe excluir.
La ubicación del .gitignore depende de ti, puedes tener un único archivo global
en el directorio principal o uno independiente dentro de cada carpeta que
quieras configurar.
=============================
Creando un archivo .gitignore
=============================
Esto es muy sencillo, básicamente es un archivo de texto plano donde debes
escribir las rutas que deseas excluir del repositorio, esto no quiere decir que
los ficheros van a ser borrados, simplemente los cambios que hagas allí no se
van a ver reflejados en ningún commit mientras la ruta se encuentre definida en
el .gitignore.
Es importante que el nombre sea exactamente ".gitignore" sin preposiciones,
símbolos o cualquier otro caracter diferente a esto.
Supón que tienes el siguiente directorio:
--index.php
--assets
css
main.css
variables.css
--js
sidebar.js
main.js
--contact.php
--config.php
--server_config.php
Digamos que en tu archivoserver_config.php tienes información delicada sobre
conexiones a tu servidor que no quieres incluir en el repositorio para
compartirlo con tus colaboradores, ese tal vez sea el primer archivo que quieras
excluir, para ello creas el archivo .gitignore y agregas la siguiente linea:
server_config.php
Ahora git incluirá todo el directorio menos ese archivo:
--index.php
--assets
css
main.css
variables.css
--js
sidebar.js
main.js
--contact.php
--config.php
XXX - server_config.php
Bien, tal vez la carpeta assets/js se haya creado para hacer algunas pruebas de
forma local y aun no quieras incluirla en el commit:
server_config.php
assets/js
Cuando referencias a una carpeta, todo lo que está dentro de ella se incluye
como parte de los archivos sin seguimiento, pero si solo se quisiera
omitir el contenido entonces sería
assets/js/
====================================================
Ignorando un fichero que no se deja en el .gitignore
====================================================
Cuando un fichero ya está bajo el control de versiones de git, git seguirá
rastreando el archivo, no importa lo que escriba en .gitignore. Tienes que decir
explícitamente a git que se olvide de ese fichero con:
1) Agregar el fichero a ignorar en el .gitignore
2) Remover el fichero del seguimiento con:
$ git rm --cached projectname/settings.py
3) Hacer el commit del cambio con:
$ git commit -m "Removido settings del seguimiento"
===========================
Ignorando settings globales
===========================
Es probable que en algún momento se trabaje con un proyecto modular, es decir
que los componentes de dicho proyecto pueden ser ejecutados por separado pero a
su vez se pueden comunicar cuando se necesite, entonces, al ser sub proyectos o
aplicaciones es posible que cada uno posea un fichero de configuración y que por
alguna razón queremos ignorarlo, si estas aplicaciones forman parte de un
proyecto entonces es posible que tengas un fichero .gitignore global y que
abarca todos los subdirectorios, entonces de manera manual, si queremos omitir
esos archivos de configuración sería tal que asi:
project/app1/settings
project/app2/settings
Con eso estaríamos omitiendo los settings de esas aplicaciones
pero si declaramos un settings en el gitignore
settings
Entonces se omitiran de manera global todos los ficheros que coincidan, es
decir, no hay que especificar la ruta completa de los ficheros a omitir, para
este caso, puede ser que si lo amerite para otro casos.
====================
El fichero README.md
====================
README (en español LEEME o LEAME) es un documento de texto que acompaña
normalmente a los programas (Proyectos), en el cual hay información de
relevancia sobre éste en cuanto a su uso, nuevas características, errores (bugs)
y requisitos de software o hardware.
Generalmente se distribuye en formato de texto plano, aunque también puede estar
en otros formatos que permiten agregar estilos como Encabezados, subrayados,
listas, enlaces, imágenes, etc.
Generalmente la estructura del fichero debería ser la siguiente:
*****
-Languaje version
-System dependencies
-Configuration
-Database creation
-Database initialization
-How to run the test suite
-Services (job queues, cache servers, search engines, etc.)
-Deployment instructions
*****
Es posible omitir algunas, lo que se desea es que el que lea este fichero, pueda
correr con éxito el proyecto siguiendo los pasos descritos.
Con (#) escribimos comentarios dentro de un fichero .gitignore
=================================
Ejemplo de .gitignore para Django
=================================
*.*.backup
*.*~
*.tar.gz
*.pyc
*.pyo
*.log
*.swp
*.sqlite3
*.db
#/project/app/migrations
#/project/settings.py
==============================================
Ejemplo de .gitignore para archivos temporales
==============================================
# Temporary files of every sort
*~
*.swp
*.swp~
===================================================================
Eliminando varios archivos de Git que ya se han eliminado del disco
===================================================================
$ git add -u
$ git commit -m "Deleted files manually"
======================================================================
Agregar archivo al seguimiento de git si está omitido en el .gitignore
======================================================================
$ git add -f ruta/del/archivo/archivo.txt
===============
Mezclando ramas
===============
Para fusionar dos ramas, en este caso una rama de desarrollo con la rama master
se hace un git merge, para realizar la mezcla vamos a situarnos en la rama
master, y luego escribimos el comando donde especificamos que rama queremos
mezclar con master.
Tambien está el caso de una mezcla de versiones de una rama, ya sea de la rama
master local, con la rama master del repositorio, entonces si se hace un pull y
hay conflictos hay que arreglarlos manualmente y luego hacer el commit, por
ejemplo "Fix conflicts", si se hace la mezcla y no hay conflictos entonces el
propio git te ofrecera crear el commit, algo parecido a "Merge branch xxx in to
xxx"...
Cambiarsa a la rama master
$ git checkout master
Mezclar la rama desarrollo con master, si hay conflictos tal vez se tengan que
resolver (automáticamente) antes de mezclar.
$ git merge desarrollo
Recuperar y unir automáticamente la rama remota con tu rama actual, traerse los
cambios del repo al repo local. A veces puede haber conflictos con ficheros
locales y no deja hacer el pull, por lo que es necesario descartar esos
ficheros.
$ git pull origin master
Descartar cambios, probar el pull de nuevo
$ git checkout
Si no deja hacer el pull, descartar cambios en ese fichero/s para poder hacer
el pull.
$ git checkout fichero.xxx
Comparar la rama local con la rama del repositorio, nos dirá si estamos atrás o
delante del repo, y por cuantos commits.
$ git status origin master
Si estamos detrás, con un pull nos traeremos los cambios del repo, si estamos
delante, se hará un merge o una mezcla del repo local y el remoto y así tendra
todos los cambios listos, luego en el status del repo local, pedirá hacer un
push para estabilizar todos los cambios en el repo remoto.
======================
Borrando ramas remotas
======================
Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus
colaboradores habeis completado una determinada funcionalidad y la habeis
incorporado (merge) a la rama master en el remoto (o donde quiera que tengais la
rama de código estable). Puedes borrar la rama remota utilizando la un tanto
confusa sintaxis: git push [nombreremoto] :[rama]. Por ejemplo, si quieres
borrar la rama serverfix del servidor, puedes utilizar:
$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
- [deleted] serverfix
Y... ¡Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego
esta página, porque necesitarás ese comando y, lo más probable es que hayas
olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de
que proviene de la sintaxis git push [nombreremoto] [ramalocal]:[ramaremota]. Si
omites la parte [ramalocal], lo que estás diciendo es: "no cojas nada de mi lado
y haz con ello [ramaremota]".
-----
Este comando sirve para moverse entre los commits, cada commit genera una
etiqueta, un identificador muy largo alfanumerico, estas etiquetas identifican
una version del proyecto lo que permite restaurar el proyecto a estados
anteriores donde XXXXXX123456 representa la etiqueta del commit al que queremos
ir.
$ git checkout XXXXXX123456
Una vez movidos a ese commit especifico del historial se puede crear una nueva
rama desde ese punto con:
$ git checkout -b Nombre_Rama
Si hacemos git log nos mostrara los commits que habian hasta ese momento y el
ultimo es en el que nos encontramos, si queremos volver a tener los commits
anteriores solo hacemos git checkout a la rama en que estabamos antes o a alguna
rama especifica.
-----
Para forzar volver a la rama master por ejemplo, a veces no nos deja porque no
commitemos algunos cambios, como logs, etc.
$ git checkout -f master
-----
Si se hacen cambios o se agregaron archivos al proyecto este comando nos hará
mostrara una comparacion entre los ultimos cambios hechos el ultimo commit hecho
,es recomendable revisar esos cambios antes de agregarlos al seguimiento de git
y por supuesto antes de hacer un commit.
$ git diff
-----
Comparar diferencias entre la rama local y la del repositorio:
$ git diff <remote-branch> <local-branch>
$ git diff origin/develop develop
Si solo quieres ver los fichero modificados usamos --stat:
$ git diff origin/develop develop --stat
-----
Muestra la lista de ficheros modificados luego del último cambio.
$ git diff --stat
-----
Mostrar los ficheros modificados de dos commits específicos.
$ git diff --stat xxxxxxx xxxxxxx
-----
Mostrar las modificaciones de un fichero o más entre dos commits específicos,
los ficheros se separan con espacio y no con comas.
$ git diff xxxxxxx xxxxxxx file_name.xxx
-----
Ver solo los cambios o modificaciones de ese fichero, por ejemplo:
$ git diff nombre_fichero.xxx
-----
Si hacemos un git status y se muestra:
# modified: a.txt
# modified: b.html
# modified: b.py
Mostrar solo los cambios del fichero especificado.
$ git diff a.txt
---------
Luego de hacer el commit en la rama master y luego de haber creado la rama
desarrollo y hacer el commit se pueden listar los commits de las ramas
existentes y asi poder realizar comparacaiones entre las diferentes versiones
del codigo. En este caso se agregaron 2 lineas al <div id="cabecera"> de una
plantilla del proyecto
Usando los identificadores de cada commit se pueden comparar las versiones del
software.
$ git branch -v
* desarrollo e6dcbf4 Modificacion de texto de la cabecera
master a537ef5 Primer commit
user@debian:~/DIV$ git diff a537ef5 e6dcbf4
diff --git a/principal.html b/principal.html
index 554fd4f..94b3eac 100755
--- a/principal.html
+++ b/principal.html
@@ -14,6 +14,8 @@
<div id="cabecera">
CabeceraXXX
+ CabeceraXXX
+ CabeceraXXX
</div>
<div id="cuerpo1">
Crea una copia local del repositorio se debe situar en la carpeta onde se quiere
hacer la copia y luego se le da la ruta del proyecto a copiar .
$ git clone /home/directorio/proyecto/proyecto
Si esta subido en algun servidor.
$ git clone https://xxx.xxx.gob.ve/xxx/xxx/xxx.git
===========
Recomendado
===========
-Cada desarrollador o equipo de desarrollo puede hacer uso de Git de la forma
que le parezca conveniente. Sin embargo una buena práctica es la siguiente:
Se deben utilizar 4 tipos de ramas: Master, Development, Features, y Hotfix.
-Master: Es la rama principal. Contiene el repositorio que se encuentra
publicado en producción, por lo que debe estar siempre estable.
-Development: Es una rama sacada de master. Es la rama de integración, todas las
nuevas funcionalidades se deben integrar en esta rama. Luego que se realice la
integración y se corrijan los errores (en caso de haber alguno), es decir que la
rama se encuentre estable, se puede hacer un merge de development sobre la rama
master.
-Features: Cada nueva funcionalidad se debe realizar en una rama nueva,
específica para esa funcionalidad. Estas se deben sacar de development. Una vez
que la funcionalidad esté pronta, se hace un merge de la rama sobre development,
donde se integrará con las demás funcionalidades.
-Hotfix: Son bugs que surgen en producción, por lo que se deben arreglar y
publicar de forma urgente. Es por ello, que son ramas sacadas de master. Una vez
corregido el error, se debe hacer un merge de la rama sobre master. Al final,
para que no quede desactualizada, se debe realizar el merge de master sobre
development.
Algo de teoría...
================
¿Qué es un fork?
================
La palabra fork se traduce al castellano, dentro del contexto que nos ocupa,
como bifurcación. Cuando hacemos un fork de un repositorio, se hace una copia
exacta en crudo (en inglés “bare”) del repositorio original que podemos utilizar
como un repositorio git cualquiera. Después de hacer fork tendremos dos
repositorios git idénticos pero con distinta URL. Justo después de hacer el
fork, estos dos repositorios tienen exactamente la misma historia, son una copia
idéntica. Finalizado el proceso, tendremos dos repositorios independientes que
pueden cada uno evolucionar de forma totalmente autónoma. De hecho, los cambios
que se hacen el repositorio original NO se transmiten automáticamente a la copia
(fork). Esto tampoco ocurre a la inversa: las modificaciones que se hagan en la
copia (fork) NO se transmiten automáticamente al repositorio original.
¿Y en qué se diferencia un fork de un clon?
Cuando hacemos un clon de un repositorio, te bajas una copia del mismo a tu
máquina. Empiezas a trabajar, haces modificaciones y haces un push. Cuando haces
el push estás modificando el repositorio que has clonado.
Cuando haces un fork de un repositorio, se crea un nuevo repositorio en tu
cuenta de Github o Bitbucket, con una URL diferente (fork). Acto seguido tienes
que hacer un clon de esa copia sobre la que empiezas a trabajar de forma que
cuando haces push, estás modificando TU COPIA (fork). El repositorio original
sigue intacto. Lo vamos a ver en breve con un ejemplo.
¿Para qué sirve?
Tiene varios usos. El más común es el de permitir a los desarrolladores
contribuir a un proyecto de forma segura.
¿Porqué decimos de forma segura? Imaginaos un super proyecto como puede ser el
código fuente de Apache. ¿Cómo se trabajaba antes de existir git? con Subversion
o CVS existía un servidor centralizado que tenía dos tipos de usuarios: lo que
podían “escribir” en el repositorio (subir cambios al código fuente) y los que
sólo podían “leer” el repositorio. Estos últimos sólo podían bajarse el código a
su máquina y podían modificarlo sólo en su copia local. No podían subir ninguna
modificación al servidor central.
¿Qué tenías que hacer para contribuir? Tenías que solicitar permiso de escritura
y que alguien te lo diese. Una vez te lo concedían, ya podías subir tus
modificaciones y, por supuesto, liarla si no sabías lo que estabas haciendo.
Otra opción era enviar parches, trabajar con ramas… había varias formas pero
todas bastante engorrosas.
Además, este procedimiento de dar acceso de escritura a un repositorio
centralizado es un poco arriesgado. Siguiendo con el ejemplo que he puesto de
Apache ¿cómo sé yo, responsable del repositorio, que esta persona que está a
10000Km de mí en la otra punta del planeta sabe lo que está haciendo? ¿puedo
confiar en él?. Al final, contribuir a un proyecto se convertía en una tarea
tediosa tanto para el que pretendía contribuir como para el que lo tenía que
gestionar. Y no hablemos de lo divertido que era hacer un merge…
Git, al tratarse de un sistema distribuido, resuelve este tipo de problemas de
una forma muy elegante a través de los forks. Digamos que Pepito es una persona
quiere contribuir al proyecto. Ha encontrado un bug y sabe cómo corregirlo. Como
propietario del repositorio me interesa que Pepito pueda enviarme el parche de
forma rápida, que no pierda mucho tiempo. Si es así ¡Pepito estará encantado de
colaborar con nosotros! ;-). Además, necesito que el proceso sea ágil, no quiero
tener que invertir 5 horas de mi tiempo cada vez que tenga que hacer un merge
del trabajo que Pepito me envíe. ¿Cómo resuelve git el problema?
-Pepito hace un fork de mi repositorio, para lo que sólo necesito darle permiso
de lectura.
-Pepito trabaja en SU COPIA (fork) del repositorio. Como es suya, puede hacer lo
que quiera, la puede borrar, corromper, dinamitar, reescribir la historia del
proyecto… nos da lo mismo, es SU COPIA (fork).
-Cuando Pepito termina de programar y testear el parche, me avisa de que ya lo
tiene y me dice “En la rama parche_de_pepito de MI COPIA (fork), tienes el
parche que corrige el Bug XXXX”.
-Yo voy a su repositorio, miro lo que ha hecho y si está bien lo incorporo
(merge) a mi repositorio, que es el original.
Las ventajas de este proceso son las siguientes:
-Pepito trabaja con SU COPIA. En ningún momento le tengo que dar acceso al
repositorio central.
-El proceso de incorporación de los cambios de Pepito es muy sencillo. Si no hay
conflictos en los ficheros puede que sea tan simple como ejecutar un par de
comandos git.
-Pepito tiene muy fácil contribuir, no le cuesta esfuerzo.
-Yo puedo gestionar muy fácilmente las contribuciones de muchas personas ¡me
cuesta muy poco trabajo!
========================
Subir proyectos a GitHub
========================
Repositorio: Un repositorio, depósito o archivo es un sitio centralizado donde
se almacena y mantiene información digital, habitualmente bases de datos o
archivos informáticos.
1- Crearnos una cuenta en GitHub
2- Crear un repositorio, desde la intefáz gráfica de github nos pedirá el nombre
para el repositorio ese repo tendra una URL asignada, ejem:
https://github.com/name_user/name_repo
3- La forma mas rápida de subir un proyecto al repositorio creado es bajando ese
repositorio creado, clonandolo en nuestro directorio, al clonarlo ya viene
configurado con los ficheros de git lo que nos permitira hacer push directamente
sin hacer mayores esfuerzos.
Clonamos el repositorio del proyecto, se guardará en nuestro directorio.
$ git clone https://github.com/name_user/name_repo.git
Clonar directamente una rama específica.
$ git clone -b branch_name https://xxx.xxx.com/xxx/xxx/git/xxx.git
Nos cambiamos a la carpeta del proyecto
$ cd name_repo/
4- Una vez hecho es veremos una carpeta local con el nombre de nuestro
repositorio de GitHub esta carpeta estará vacía, dentro de la carpeta irá el
proyecto que queremos subir. Ahora metemos dentro de la carpeta todos los
directorios y ficehros de nuestro proyecto.
Para agregar todos los archivos que pegamos al seguimiento de git.
$ git add .
Hacemos el primer commit del proyecto, ejemplo: "Primer commit" o "Caga inicial
del proyecto"
$ git commit -m "Comentario"
Este comando es para subir el proyecto directamente a la rama master de nuestro
repo.
$ git push origin master
Cabe mencionar que en el proyecto git descargado, oculta está la carpeta .git,
dentro en el fichero config estará por defecto escrita la URL de nuestro repo,
lo que facilita subir los proyectos y los cambios directamente, por ello el paso
de la clonacion del repo.
Ejemplo de un fichero config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = https://github.com/user/Project_name.git
[branch "master"]
remote = origin