¿Es seguro "git pull" cuando mi árbol de trabajo y/o índice está sucio?

Question

Digamos que tengo un git repo cuyo árbol de trabajo y/o índice es "sucio" (es decir, tengo modificaciones locales que aún no se han confirmado o guardado) y estoy tentado de hacer un "git pull" sin primero comprometerme o escondiendo (Alternativamente, digamos que estoy presentando un nuevo miembro del equipo a git y que están tentados a ejecutar "git pull" cuando su repositorio local está "sucio"). Me pregunto qué tan seguro es hacer un " git pull "en este caso. Si no es seguro, ¿qué es lo peor que puede pasar? ¿Importa si estoy sacando de una fuente confiable o no confiable?

Mi investigación hasta el momento sugiere una gama confusa de ideas sobre lo que suponía que sería una pregunta bastante directa.

Para empezar, la página de manual git-alijo hace que suene como git pull es bastante seguro, y se abortará si estás en una situación en la que algo puede ir mal:

Pulling into a dirty tree 
     When you are in the middle of something, you learn that there are 
     upstream changes that are possibly relevant to what you are doing. 
     When your local changes do not conflict with the changes in the 
     upstream, a simple git pull will let you move forward. 

     However, there are cases in which your local changes do conflict 
     with the upstream changes, and git pull refuses to overwrite your 
     changes. In such a case, you can stash your changes away, perform a 
     pull, and then unstash, like this... 

Esto parece realmente a sea ​​lo que pase también, en mis simples pruebas hasta ahora.

también quizá lo que implica que "git pull" es bastante seguro, la barra de herramientas Git Extensions para Visual Studio tiene un botón de despliegue prominente que no hace un cheque por la suciedad antes de desembolsar a "git pull". (Si estuviera diseñando una barra de herramientas de Visual Studio, trataría de evitar que sea particularmente fácil dispararse en el pie.)

La página de git-pull no hace que mi sonido de "git pull" sea peligroso, aunque sugiere que no es una buena práctica:

If any of the remote changes overlap with local uncommitted changes, 
    the merge will be automatically cancelled and the work tree untouched. 
    It is generally best to get any local changes in working order before 
    pulling or stash them away with git-stash(1). 

Pero entonces también se puede encontrar consejos que tirando en una sucia es muy mala, e.g.:

Avoid git-pull! 
git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master. 
This will always lead to some dirty artifacts in the commit history 

¿hay una respuesta fácil a qué perspectiva es mejor, o es esto de alguna manera una cosa caso por caso?

Seguimiento: ¿Usaría "git pull --rebase" en lugar de simplemente "git pull" para cambiar la respuesta? Rebasing puede tener su ownpitfalls en algunos casos, pero hasta ahora supongo que tener un tree tree/index sucio no volvería una rebase más problemática de lo que sería.

Answer 1

Sin ofender a las personas que mantienen el proyecto Apache DeltaSpike, pero confío en lo que las páginas man de Git dicen sobre Git sobre los contenidos de la wiki de Delta Spike.

También tenga en cuenta que, en el texto citado (el énfasis es mío):

git-pull nunca debe quedar invocado si tiene archivos sucios tirados o si su rama está por delante de maestro. Esto siempre dará lugar a algunos artefactos sucios en el historial de confirmaciones.

Los "artefactos sucios en el historial de confirmaciones" son compromisos de fusión de Git. Esto sucede cada vez que fusionas ramas en lugar de volver a basar los contenidos de una rama en la otra.Si estas confusiones de fusión están o no "sucias" depende de su proyecto, su organización y su opinión y políticas.

En cualquier caso, git-pull nunca es una operación peligrosa. Según lo documentado, no destruirá ninguno de su historial o trabajo en progreso.

Answer 2

En mi experiencia, es absolutamente seguro (estoy usando git durante aproximadamente 4 años). Si tiene cambios sin compromiso, por lo general solo falla diciéndole que tiene una copia de trabajo sucia.

Answer 3

git pull es simplemente git fetch + ya sea rebase/merge, la combinación automatizada puede generar ruido o resultados no deseados. (Ejemplo de ruido: no necesita 10 merge commits cuando todo lo que hizo fue agregar una sola línea al mismo archivo 10 veces). Si los no iniciados simplemente hacen un git pull y push back sin verificar, el ruido ser registrado.

Yo diría que el nuevo miembro del equipo es más probable que esté desorientado después de un truco en un árbol de trabajo sucio, si es seguro o no, dependerá de la respuesta (verificando los resultados después de cada extracción será un buen comienzo).

Answer 4

git fetch 

Y a continuación, fusione, restaure o reinicie según lo que haya obtenido del servidor. Puedes usar pull y no destruirá el trabajo en progreso. Sin embargo, se prefiere el primer método.

Answer 5

Hasta ahora no estoy seguro de que esto realmente se apoya sobre git pull (que suena como pre-detecta si puede haber conflictos de fusión y aborta si no pudiera), pero tenga en cuenta que al menos tangencialmente fusión (es decir, haciendo git merge) en un árbol de trabajo sucio, aparentemente puede limitar su capacidad de "deshacer" su fusión en el caso de que la fusión se dañe. En particular, desde la página de manual git-fusión:

[merge] --abort 
     Abort the current conflict resolution process, and try to 
     reconstruct the pre-merge state. 

     If there were uncommitted worktree changes present when the merge 
     started, git merge --abort will in some cases be unable to 
     reconstruct these changes. It is therefore recommended to always 
     commit or stash your changes before running git merge. 

Answer 6

Escenario A:

Si el tirado comete entraría en conflicto con las cambios no confirmados en su árbol de trabajo, a continuación, Git sería abortar y evitar que arruine su repositorio.

Escenario B:

Si el tirado comete entraría en conflicto con los cambios confirmados en tu repositorio y también tiene cambios no confirmados en su árbol de trabajo que no entren en conflicto, entonces terminaría con un desastre en tus manos. Tendría que resolver los conflictos y comprometerse sin perder de vista los cambios que estaban en su árbol de trabajo antes de tirar.

El escenario B aparece a veces después de presentar a los nuevos miembros del equipo a Git. Un error común de los nuevos miembros de mi equipo es cambiar accidentalmente/por negligencia los archivos en nuestros repositorios de unidad de red, en lugar de hacerlo en sus clones locales como se supone que deben hacerlo, ¡y también se olvidan de realizar esos cambios!

Como un lado, una forma de protegerse de los errores cometidos por su equipo es recurrir primero a un repositorio local limpio, hacer frente a los conflictos locales y luego retirar de su repositorio local el repositorio que comparte con su equipo. Este paso adicional evita el Escenario B y hace que el árbol sucio sea transparente para usted o, en el peor de los casos, le presenta el Escenario A. Afortunadamente, el Escenario A se puede tratar como un conflicto normal, sin los dolores de cabeza del Escenario B.