├── LICENSE ├── README.md ├── git-000.png ├── git-001.png ├── git-002.png ├── git-003.png ├── git-004.png ├── git-005.png └── git-006.png /LICENSE: -------------------------------------------------------------------------------- 1 | BSD 3-Clause License 2 | 3 | Copyright (c) 2018, Cristian J. Azulay 4 | All rights reserved. 5 | 6 | Redistribution and use in source and binary forms, with or without 7 | modification, are permitted provided that the following conditions are met: 8 | 9 | * Redistributions of source code must retain the above copyright notice, this 10 | list of conditions and the following disclaimer. 11 | 12 | * Redistributions in binary form must reproduce the above copyright notice, 13 | this list of conditions and the following disclaimer in the documentation 14 | and/or other materials provided with the distribution. 15 | 16 | * Neither the name of the copyright holder nor the names of its 17 | contributors may be used to endorse or promote products derived from 18 | this software without specific prior written permission. 19 | 20 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 21 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 23 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 24 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 26 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 27 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 28 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 29 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 30 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Tutorial y uso de Git y Git Flow 2 | 3 | [Git-Flow](http://aprendegit.com/que-es-git-flow/) es un conjunto de extensiones para [Git](https://git-scm.com/) que proveen comandos de alto nivel para operar repositorios basados en el [modelo de ramificaciones de Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/). 4 | 5 | Si queremos implementar este flujo de trabajo, cada vez que queramos hacer algo en el código, tendremos que crear la rama que corresponda, trabajar en el código, incorporar el código donde corresponda y cerrar la rama. A lo largo de nuestra jornada de trabajo necesitaremos ejecutar varias veces al día los comandos git, merge, push y pull así como hacer checkouts de diferentes ramas, borrarlas, etc. Git-flow son un conjunto de extensiones que nos ahorran bastante trabajo a la hora de ejecutar todos estos comandos, simplificando la gestión de las ramas de nuestro repositorio. 6 | 7 | Las "reglas" que Vincent plantea en su blog son un ejemplo de cómo git nos permite implementar un flujo de trabajo para nuestro equipo. Estas no son reglas absolutas, bien es cierto que pueden funcionar en un gran número de proyectos, aunque no siempre será así. Por ejemplo ¿qué pasa si tenemos que mantener dos o tres versiones diferentes de una misma aplicación? Digamos que tenemos que mantener la versión 1.x, la 2.x y la 3.x. El tablero de juego es diferente así que necesitaremos ampliar y adaptar estas reglas para poder seguir jugando. 8 | 9 | Git es una herramienta que nos permite modificar estas reglas y, lo que es más importante, cambiando y adaptándolas a medida que el proyecto avanza y el equipo madura. Una vez más, una buena dosis de sentido común será nuestra mejor aliada para responder las preguntas que nos surjan durante el camino. 10 | 11 | ## Instalación y Configuración 12 | 13 | Un pre-requisito es una instalación de Git en funcionamiento. Git Flow funciona en OSX, Linux y Windows. 14 | 15 | El cliente gráfico para OSX y Windows [Sourcetree](https://www.sourcetreeapp.com/) es una excelente GUI para git y tiene soporte para git-flow nativo. [GitKraken](https://www.gitkraken.com/) es una opción para los que quieren trabajar con Git Flow y un cliente gráfico que también soporte Linux. 16 | 17 | ### OSX - Homebrew 18 | 19 | ```shell 20 | brew install git-flow-avh 21 | ``` 22 | 23 | ### OSX - Macports 24 | 25 | ```shell 26 | port install git-flow-avh 27 | ``` 28 | 29 | ### Linux 30 | 31 | ```shell 32 | apt-get install git-flow 33 | ``` 34 | 35 | ### Windows (Cygwin) 36 | 37 | ```shell 38 | $ wget -q -O - --no-check-certificate 39 | https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh 40 | install stable | bash 41 | ``` 42 | 43 | ## Introducción 44 | 45 | Git-flow parte de la idea de un repositorio central remoto (que por defecto es origin). Se puede trabajar localmente con esta idea también pero la potencia la va a dar trabajar con un repo remoto. 46 | 47 | Git-flow funciona basándose en **merges** o _fusiones de ramas_. No reorganiza (branch rebase) las **features branches** o _ramas de características_. 48 | 49 | Git Flow, la mayoría de las veces que hace merges a **master** o **develop**, lo hace con la opción `--no-ff` _no fast-forward_ para asegurar que Git no haga la construcción de un _avance rápido_ sino que mantenga la de una _fusión_, así se mantiene una topología de bifurcación, como lo muestra la figura de abajo. Y digo, "la mayoría", porque como bien lo explica el autor en el [issue 100](https://github.com/nvie/gitflow/issues/100) del repositorio de GitFlow: 50 | 51 | > Por diseño, git-flow usa la opción `--no-ff` cuando se fusiona para registrar que los commits pertenecen juntos históricamente. Sin embargo, cuando la rama de `features` contiene solo un commit, la confirmación de fusión adicional no agrega nada y solo complica innecesariamente el árbol de las ramas. Por lo tanto, para las ramas con un solo commit, las fusiones de avance rápido se realizan como si la confirmación se hubiera realizado en `develop` directamente. - Vincent Driessen 52 | 53 | Un **_avance rápido_** es cuando, en lugar de construir un commit de fusión, git simplemente mueve su puntero de la rama para apuntar a la confirmación entrante. Esto ocurre comúnmente al hacer un _git pull_ sin ningún cambio local. 54 | 55 | ![Siempre fusionar con la opción de "avance rápido"](git-000.png) 56 | 57 | ## Ramas Principales (main branches) 58 | 59 | El trabajo se organiza en dos ramas principales: 60 | 61 | * Master 62 | * Develop 63 | 64 | ### Rama Master (master branch) 65 | 66 | Cualquier commit que pongamos en esta rama debe estar preparado para subir a producción. Es la rama donde iniciamos nuestro proyecto y desde donde se clonará siempre nuestro proyecto. _**No se hacen commit aquí**_ (salvo raras excepciones de correcciones muy tontas) 67 | 68 | ![Rama Master](git-001.png) 69 | 70 | ### Rama Develop (develop branch) 71 | 72 | Rama en la que está el código que conformará la siguiente versión planificada del proyecto. **_No se suelen hacer commits aquí_. Solo merges.** 73 | 74 | ![Rama Develop](git-002.png) 75 | 76 | ## Ramas de Soporte 77 | 78 | * Feature 79 | * Realese 80 | * Hotfix 81 | 82 | ### Rama de Características (feature branch) 83 | 84 | Estas ramas se utilizan para desarrollar nuevas características de la aplicación que, una vez terminadas, se incorporan a la rama develop. **Es donde trabajaremos en el día a día y donde haremos nuestro commits.** 85 | 86 | * Se originan a partir de la rama Develop. 87 | * Se incorporan siempre a la rama Develop. 88 | * Nombre: cualquiera que no sea master, develop, hotfix-* o release-* 89 | 90 | ![Rama Feature](git-004.png) 91 | 92 | ### Rama de Versión (realese branch) 93 | 94 | Estas ramas se utilizan para preparar el siguiente código en producción. En estas ramas se hacen los últimos ajustes y se corrigen los últimos bugs antes de pasar el código a producción incorporándolo a la rama Master. Esta rama "congela" la rama Develop. Parte de ella, a diferencia de Hotfix que, como veremos, parte de Master ("congela" a master como se dice habitualmente) 95 | 96 | En la rama de versionado, se pueden hacer cambios menores referentes a configuraciones de la release como ser: archivos de configuraciones, archivos de librerías de la versión, correcciones muy menores para salir a producción, pero solo eso. No hay desarrollo de características aquí ni correcciones de bugs. 97 | 98 | * Se originan a partir de la rama Develop 99 | * Se incorporan a Master y Develop. 100 | * Cuando se incorpora a Master se hace un tag con un versionado semántico (tres cifras: mayor-version.menor-version.patch-version) 101 | * Nombre: release-* 102 | 103 | ![Rama Release](git-005.png) 104 | 105 | ### Rama de Corrección de Errores (hotfix branch) 106 | 107 | Esas ramas se utilizan para corregir errores y bugs en el código en producción. Funcionan de forma parecida a las Releases Branches, siendo la principal diferencia que los hotfixes no se planifican. Parten de Master. Los cambios que se hagan aquí irán a producción. 108 | 109 | * Se origina a partir de la rama Master 110 | * Se incorporan a la Master y Develop 111 | * Nombre: hotfix-* 112 | 113 | ![Rama Hotfix](git-006.png) 114 | 115 | Las ramas de Realese y Hotfix son las únicas permitidas para incorporar cambios (commits) a la rama master. Para decirlo de otro modo: **Master solo puede recibir merges de Realise y/o Hotfix** 116 | 117 | Mientras que **las Features siempre irán a Develop.** 118 | 119 | ## Tools en acción 120 | 121 | 122 | 123 | ## Referencias 124 | 125 | * 126 | * 127 | * 128 | * 129 | * 130 | -------------------------------------------------------------------------------- /git-000.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-000.png -------------------------------------------------------------------------------- /git-001.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-001.png -------------------------------------------------------------------------------- /git-002.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-002.png -------------------------------------------------------------------------------- /git-003.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-003.png -------------------------------------------------------------------------------- /git-004.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-004.png -------------------------------------------------------------------------------- /git-005.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-005.png -------------------------------------------------------------------------------- /git-006.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cjadeveloper/gitflow-tutorial/674a7d7035a9ffa1eefac704379c7e9fde89482f/git-006.png --------------------------------------------------------------------------------