2010-08-24 17 views
9

Antes de comenzar a usar Git como mi SCM, probaba "a fondo" el código para la estabilidad, entonces simplemente copiaba el directorio de trabajo y lo cambiaba a algo así como (date) project_name . Entonces, si metí la pata en algún lado y no pude desenterrarme, empezaría desde el último directorio estable. Entonces escuché acerca de Git.Learning Git. Necesito saber si estoy en el camino correcto

Quiero saber si estoy usando Git correctamente hasta ahora. Esto es lo que he estado haciendo:

  1. escribir código ...

  2. git add . para añadir todos los archivos modificados a la etapa

  3. git status para comprobar si esos archivos modificados son listo para ser cometido

  4. git commit para confirmar los últimos cambios y escribir un mensaje de confirmación

  5. repetición

Hasta el momento esto es todo lo que he estado haciendo. Para fines simples de copia de seguridad y para la capacidad de volver a una "estabilidad previa" ¿es este conocimiento suficiente de Git? Si no, ¿qué más debería saber?

+0

¡Gracias a todos por la excelente contribución! Aprecio tu ayuda. – BasicObject

Respuesta

7

Si todo lo que quiere hacer es restablecer a un antiguo compromiso cuando algo sale mal, entonces sí, eso es todo. Aunque se puede combinar todos los pasos git en uno con:

git commit -a 

(que compromete a todos los archivos modificados orugas)


Me gustaría ver en rama o una etiqueta, si tienes tiempo, pero son no estrictamente requerido para lo que estás haciendo, simplemente tienden a facilitar la vida

+0

¡Gracias por la rápida respuesta del rayo! – BasicObject

+0

@ user284194 - Etiquetado en particular - le permite marcar una compilación de 'lanzamiento' que está actualmente con sus clientes. – Paddy

+0

+1, fíjate en el etiquetado y la bifurcación, ya que es posible que no funcionen cómo crees que lo hacen. –

2

Uso gitk --all para visualizar mi historial de revisión y cambios no confirmados en todas las ramas, y uso git commit -am "commit message" para agregar y confirmar en un comando.

También recomendaría utilizar las ramas liberalmente. Hago desarrollo web, así que haré que la rama principal refleje el estado del código en el servidor, y crearé una nueva rama cada vez que esté trabajando en una gran función. De esta forma, si tengo una solución de emergencia, puedo verificar fácilmente la rama principal, comprometer y cargar la solución y volver a fusionarla en la función en progreso.

1

Y para una forma práctica para previsualizar los cambios antes de añadirlos,

git diff 
3

Sí, lo estás haciendo las cosas bien :) antes de comprometerse, a veces es una buena idea ejecutar el siguiente comando:

git difftool 

Esto le permitirá realizar todos los cambios de código en su herramienta de diferencia favorita (por ejemplo, Beyond Compare, KDiff3, etc.). Simplemente presione intro para abrir la herramienta, asegúrese de que todo esté bien y cierre el programa. Luego presiona enter nuevamente para modificar automáticamente el siguiente archivo modificado.

Si está utilizando Windows, here's a good tutorial sobre cómo configurar su herramienta de diferencia (y fusión) favorita.

8

Como han mencionado otros, recomiendo sentirse cómodo con las ramas. Mi flujo de trabajo es típicamente:

Arranque forman la rama principal *:

  • git checkout -b awesome-new-killer-feature crear una nueva rama (-b) y se debe verificar.

  • escribir código ...

  • git add ., git status, git commit confirmar los cambios pequeños, repita el paso 2

Oh no! ¡Mi amigo acaba de informar un error grave! Perdió datos !!!!!

  • git checkout master volver a la rama principal

  • git checkout -b bugfix-serious-data-loss crear nueva rama de revisión

  • arreglar errores, git add, git status, git commit, enjuague, repita la operación hasta error se corrige

  • git checkout master volver a la rama principal

  • git merge --no-ff bugfix-serious-data-loss de combinación de corrección de errores de nuevo en maestro

bien, ahora puedo volver a trabajar en mi increíble-new-killer-feature:

  • git checkout awesome-new-killer-feature hoja de vida trabajando en lo que estaba trabajando en

  • git rebase master fusionar los cambios a la copia maestra en el código de trabajo para que podamos obtener el beneficio de la corrección de errores. Por no hablar de que esto reduce la probabilidad de conflictos de fusión más adelante, cuando tenemos que combinar esta rama de nuevo a dominar

  • código de escritura, git add, git status, git commit, enjuague, repita la operación hasta característica es completa

  • git checkout master, git merge --no-ff awesome-new-killer-feature fusionar la rama de nuevo en maestro

Ahora siéntese y escriba gitk para ver una vista histórica agradable de lo que has estado haciendo.

Opcional:

  • git branch -D bugfix-serious-data-loss awesome-new-killer-feature eliminar ramas no utilizados.Me gusta mantener mi repositorio limpio

El poder de git no proviene de poder hacer un punto de control de su trabajo. Viene de qué tan rápida y barata es la ramificación &. La ramificación le permite trabajar en múltiples ideas al mismo tiempo y/o experimentar con ideas desechables sin afectar su código estable. Si la idea no funciona, simplemente elimine la rama, si funciona, vuelva a fusionarla en el maestro.

* nota: Por convención, la mayoría de los usuarios de git llaman a su rama principal/troncal "maestra".

+0

¿Por qué las banderas '--no-ff'? –

+0

La bandera --no-ff obliga a git a tratar la fusión para tener dos padres en lugar de marcar la fusión. La ventaja de esto es que cuando utilizas herramientas como 'gitk' o' git log -graph' es más fácil ver grupos de cambios. – slebetman

Cuestiones relacionadas