Si en el momento de crear una rama utilizas como nombre una ruta, como por ejemplo “mi-carpeta-de-ramas/nombre-de-rama”, verás que en la carpeta .git/refs/heads de tu repositorio se creará una subcarpeta “mi-carpeta-de-ramas”. Dentro de la misma verás el fichero “nombre-de-rama” con la referencia. Es decir, git convierte la cadena con formato de ruta que pasamos como argumento en una estructura real de carpetas.
Esta forma de crear ramas soporta subcarpetas, es decir, si creamos una rama que se llame carpeta1/carpeta2/mirama:
$ git checkout -b carpeta1/carpeta2/mirama
git creará el fichero .git/refs/heads/carpeta1/carpeta2/mirama con la referencia.
¿Y cómo muestra SourceTree las ramas creadas de esta manera?
Esta forma de clasificar las ramas en carpetas es especialmente útil cuando trabajamos con ramas para hacer hotfixes, corregir bugs o desarrollar funcionalidades organizadas en historias de usuario.
Desde la interfaz de línea de comandos, así es como veríamos las ramas:
$ git branch -av carpeta1/carpeta2/mirama 4604003 Introduciendo el texto definitivo develop b7bd517 Merge branch ‘feature-H-1’ into develop * feature/H-2 4604003 Introduciendo el text definitive master 87ee184 Initial commit
Si quisiésemos ver sólo las ramas feature, podemos usar la opción –list:
$ git branch --list feature* feature/H-2
Para borrar la rama, usamos el comando git-branch con la ruta completa a la rama:
$ git branch -D carpeta1/carpeta2/mirama
Un truco muy sencillo que nos ayuda a organizar las ramas un poco mejor, especialmente útil si estáis usando SourceTree.
Hola Alfonso, en primer lugar déjame felicitarte por el blog es un verdadero repositorio de lujo en cuanto a lo que información y documentación de Git respecta.
Te quería hacer una pregunta un tanto concreta de Git, y no sé bien donde dejártela, lo hago por aquí para que cuando lo resolvamos los lectores puedan aprovechar el feedback.
Verás, estoy en un escenario bastante común. Tengo varias ramas: develop, uat, master… de un website. Entonces tengo un fichero settings.php en el que, entre otras cosas, se guardan los datos de conexión a la Base de Datos.
Quiero versionar este fichero, pero necesitaría que cada entorno mantuviera su versión y al hacer merges entre ramas no se «machacara». El gitignore no me vale, porque pierdo el versionado del fichero.
He investigado un poco y parece que los gitatributte pueden servir: http://librosweb.es/pro_git/capitulo_7/atributos_de_git.html pero no acabo de conseguir lo que quiero, y cuando voy a hacer un merge de develop a uat me detecta diferencias y me obliga a comitear cambios en el settings antes de mergear.
Mi fichero .gitattribute contiene sólo esto:
sites/*/settings*.php merge=oursPor lo general uso SourceTree pero no tengo problema moviéndome por terminal, podrías echarme algo de luz con el asunto?
Muchas gracias!
Finalmente lo he conseguido en parte siguiendo tu consejo, simplificando el .gitattributes poniendo el fichero en el mismo directorio que el settings.php y para no pelearme con rutas, ya que es un fichero muy concreto lo he dejado así:
settings.php merge=oursSin embargo no ha sido suficiente y he tenido que configurar un driver de merge, de esto ayer no tenía ni conocimiento 😛
Poniendo esto en el .git/config
[merge "ours"]
name = "Keep ours merge"
driver = true
Ha empezado a funcionar, supongo que tiene sentido que sin esto «no entiende» la palabra «ours», pero pensaba que el «ours» y el «theirs» eran palabras reservadas o algo, supongo que SourceTree nos abstrae un poco de esto 😛
Gracias por tu ayuda!
Hola Rubén:
Copio aquí la respuesta que te di ayer por twitter a toda prisa:
Hola. Creo que el problema puede estar en los * de la ruta la fichero. Si la expansión funciona como en .gitignore quizás ese sea el problema. Prueba a meter un fichero .gitattributes en la carpeta en la que están los settings (sites/CARPETA) y dentro de ese .gitattributes pon
settings*.php, merge=ours
Así eleminas el * de la ruta. Otra opción es que pruebes con sites/**/settings*.php.
Existe otra forma de hacer esto que no requiere el uso de atributos. Consiste en lo siguiente:
Cuando alguien clona el repositorio, debe copiar settings_ref.php a settings.php y proceder a configurar el proyecto. De esta forma puedes tener tantos clones como necesites (producción, testing, pre-producción, tu máquina, la de tus compañeros de equipo, etc) cada uno con su settings.php. Toda configuración que necesite ser guardada en el repositorio se almacena en settings_ref.php.
De esta forma, además, evitamos que por error se sobreescriba el settings.php al estar incluido en el .gitignore.
Y gracias por la información que has puesto antes sobre el driver, es la primera vez que lo veo.