¿Cuándo necesito hacer "git pull", antes o después de "git add, git commit"?

93

¿Cuál es la manera correcta?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

O

git pull
git add foo.js
git commit foo.js -m "commit"
git push

O

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

Olvidé mencionar que en este caso utilizo git addpara organizar un archivo modificado y rastreado . No incluir un archivo nuevo en el repositorio. ¿Esto cambia el orden de los comandos?

git Verde
fuente
Pregunta relacionada: stackoverflow.com/questions/813822/…
leo9r

Respuestas:

95

Creo que la mejor forma de hacerlo es:

Guarda tus cambios locales:

git stash

Actualiza la rama al código más reciente

git pull

Fusiona tus cambios locales en el código más reciente:

git stash apply

Agregue, confirme y envíe sus cambios

git add
git commit
git push

En mi experiencia, este es el camino hacia la menor resistencia con Git (en la línea de comando de todos modos).

johnjo
fuente
4
¿Puedes explicar por qué esto es mejor? ¿Qué problemas evita esto? En particular, ¿por qué es esto mejor que un simple commit> pull> push? (Siento que esta podría ser la mejor respuesta, pero no tengo suficiente información en este momento para siquiera ser considerada una buena respuesta)
Dallin
7
Quizás esto fue demasiado anecdótico, pero siempre encontré este enfoque (en la línea de comandos en lugar de con algo como sourcetree) mucho más fácil. Hacer una confirmación y luego extraer, mientras se trabaja en un equipo grande, siempre conduce a grandes conflictos de fusión, ya que git no era muy bueno fusionando mis cambios en un archivo con el archivo entrante. Al ocultarme, me permitió extraer los nuevos cambios y luego usar el código actualizado como base para agregar mis cambios a. Lidiar con los conflictos fue más fácil porque me eran más claros (ya que mis cambios ahora eran los conflictos). En retrospectiva, tal vez fue más fácil para mi situación.
johnjo
1
Entonces suena como una especie de "¿Cómo se come un elefante? Un bocado a la vez". es decir, dividir el proceso en unos pocos pasos más para simplificar las fusiones y tener menos cambios y posiblemente más claros. Tiene sentido.
dallin
¿Es necesario agregar git aquí? ¡Si todos los archivos ya están agregados al ensayo!
Sharp Edge
¿Y si no lo estás usando git stash?
Aaron Franke
76

tirar = recuperar + fusionar.

Debe comprometer lo que ha hecho antes de fusionarse.

Así que tira después de comprometerte.

Arnaud Denoyelle
fuente
8
¿Significaría esto que terminaría haciendo un compromiso adicional por cada compromiso que realiza y hace que el repositorio sea descuidado? Además, su mensaje de confirmación inicial termina seguido de un comentario de fusión cada vez. Si es así, me inclinaría a usar el método de alijo que @johnjo menciona a continuación.
Lunes,
3
@DanielM Sí, hay una confirmación adicional para la fusión (con un mensaje de confirmación predeterminado explícito). Sin embargo, esto es algo bastante bueno porque le permite verificar su última confirmación o la última confirmación de su colega o la combinación de confirmación. Si desea evitarlo y si desea colocar sus confirmaciones después de las de su colega, puede rebasehacerlo en lugar de merge. Puedes hacerlo con git commit && git rebaseo con git pull --rebase.
Arnaud Denoyelle
Gracias por el consejo, @Arnaud. Después de leer muchas preguntas de SO diferentes, este comentario lo hizo. Mi opción preferida cuando los colegas están trabajando en diferentes archivos es git pulldespués de organizar mis cambios, ya que lo encuentro más natural. Aunque me doy cuenta de que funcionan muchos flujos de trabajo diferentes (el alijo también es bueno), probablemente sea una cuestión de gustos.
sobrino
51

Sugeriría extraer de la rama remota con la mayor frecuencia posible para minimizar grandes fusiones y posibles conflictos.

Habiendo dicho eso, optaría por la primera opción:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Confirme sus cambios antes de extraer para que sus confirmaciones se fusionen con los cambios remotos durante la extracción. Esto puede resultar en conflictos con los que puede comenzar a lidiar sabiendo que su código ya está comprometido en caso de que algo salga mal y tenga que abortar la fusión por cualquier motivo.

Sin embargo, estoy seguro de que alguien no estará de acuerdo conmigo, no creo que haya ninguna forma correcta de hacer este flujo de fusión, solo lo que funciona mejor para las personas.

Jasarien
fuente
1
¿Podría ver mi actualización de la pregunta? Olvidé explicar para qué git addse usa exactamente en mi ejemplo.
Verde
1
No debería haber ninguna diferencia si se trataba de un archivo nuevo o un archivo modificado o con seguimiento. Sigue comprometiéndote y luego tira.
Jasarien
7

Creo que git pull --rebasees la forma más limpia de establecer sus confirmaciones recientes localmente además de las confirmaciones remotas que no tiene en un momento determinado.

De esta manera, no tendrá que tirar cada vez que desee comenzar a realizar cambios.

Mohyaddin Alaoddin
fuente
Esto es lo que también hago, pero solo para señalar que definitivamente hay dos escuelas principales de pensamiento sobre esto (centradas en si es mejor solucionar los conflictos entre las confirmaciones individuales o una vez en la confirmación de fusión) con el propio Linus en el campo de fusión. . Afortunadamente, la herramienta en sí no tiene opiniones, así que
úsela como
3

Desea que su cambio se ubique en la parte superior del estado actual de la rama remota. Así que probablemente quieras tirar justo antes de comprometerte. Después de eso, presione sus cambios nuevamente.

Los archivos locales "sucios" no son un problema siempre que no haya ningún conflicto con la sucursal remota. Sin embargo, si hay conflictos, la fusión fallará, por lo que no hay riesgo ni peligro al extraer antes de realizar cambios locales.

AlexE
fuente
1
No funcionará, como mencionó Arnaud, la extracción requiere que primero confirme los cambios.
Jasarien
Mi git parece feliz de tirar con muchos cambios locales. Por supuesto, si se cambian los mismos archivos en la rama remota, la parte de fusión de la extracción falla. Para crear un conflicto de fusión adecuado, tendría que comprometerme primero, seguro. Por lo tanto, si el conjunto de archivos modificados local y remotamente no está unido, extraer y luego comprometer está bien. De lo contrario, git no tirará. No se puede hacer daño al intentarlo.
AlexE
Esta es mi opción preferida cuando la gente está trabajando en diferentes archivos y la encuentro más natural.
sobrino