-
git mira 1 carpeta y todas sus subcarpetas
-
git en local y en remoto son el mismo producto, la única diferencia es que en local existe la Working Copy
- El repositorio remoto recibe el nombre de origin
- Para enviar los commits desde el repo local al remote hay q hacer un Push
- Para obtener el contenido por primera vez de un Repo remoto hacemos Clone
- Para obtener los commits del repo remoto al local hacemos Pull/Fetch
- Crear un fichero en la carpeta/subcarpetas no implica que lo controle git (Tracked) sino hay que hacer Stage
-
Para que lo controle git hay que añadirlo al Stage
- Los ficheros creados, modificados, borrados aparecen en la rama Working Copy
- Cuando hacemos Commit, lo estamos haciendo sobre nuestro Repo Local. Debemos proporcionar un mensaje q debería ser indicativo
- Si las modificaciones que hemos hecho en el Working Copy, queremos deshacerlas completamente o parte de ellas, tanto Tower como SourceTree, lo permiten hacer (Discard Local Changes, Reset file to Commit respectivamente)
- Si nos equivocamos tanto en el mensaje o en el contenido del último Commit realizado, podemos modificar haciendo otro Commit con la opción Amend
- Solo hay q tener una cosa en cuenta, el Amend (al ser un Commit) se hace sobre el Repo Local, nunca sobre un remoto
-
Siempre trabajamos sobre una rama, SIEMPRE.
- Para activar una rama como la activa hay que realizar Checkout (en Tower lo marca como HEAD)
- Las ramas son completamente aisladas, se llaman contextos
-
Para combinar los cambios de 2 ramas tenemos 2 opciones Merge/Rebase:
- Merge:
- Siempre se hace Merge sobre la Head, desde otra rama hacia la HEAD (por eso hay que fijarse cuál es la HEAD en el momento del Merge)
- Siempre podemos deshacer un Merge (Undo)
- Rebase:
- Permite fusionar 2 ramas (la HEAD y otra) para que la historia quede como si se hubiera trabajado en una sola. Por ejemplo si tengo Rama1(Head), Rama2, y se modificaron File1 en Rama1, después File2 en Rama2, y finalmente File3 en Rama1, haciendo un Rebase, nos quedará una historia como: File1, File3, File2
-
Si necesitamos tener un Working Copy completamente limpia en un momento determinado, cuando hemos estado trabajando en una nueva feature, y nos llega un correctivo urgente, podemos aplicar Stash. Stash equivale a poner todos los ficheros seleccionados en un Clipboard (se libera la Working Copy al estado inicial y todos los ficheros modificados quedan almacenados en una Stash)
- Podemos tener tantos Stashes como queramos
-
Gestión de conflictos sobre un fichero concreto:
- Se dan por aplicar las acciones de: Merge, Rebase, Cherry-Pick
- Solo se puede dar en la máquina local
- Se puede hacer Undo mediante Abort, antes de realizar el Commit
-
Deshacer Commits
- Revert: crea un nuevo Commit, deshaciendo los cambios del Commit que estamos queriendo eliminar
- Reset: elimina todos los Commits desde uno en concreto en adelante y no son visibles en la historia
-
Tags permiten etiquetar Commits importantes, por ejemplo para marcar Releases
- Se puede borrar un Tag y no tiene ninguna afectación
- Cuando hacemos Push a servidor remoto los Tags por defecto no se transmiten, es necesario indicarlo
-
Cuando trabajamos con un Repositorio remoto:
- Los Commit en el repo local que no se han subido al remoto se denominan como Ahead
- Los commits en el remoto que aún no se han descargado en local se denominan Behind
- Cuando hacemos push/pull se realiza de commits de una única rama: siempre se transfieren los Commits con Push desde la HEAD a la rama que queramos del remote
- Si vamos a realizar un Push, y tenemos commits behind, git nos obliga a intregarlos previamente y no podemos realizar el Push
- Descargar los cambios del remote:
- Fetch: descarga los cambios, pero deja la Working Copy Local intacta
- Pull: realiza lo q Fetch + integra los cambios en la rama HEAD directamente de nuestro repo Local