¿Qué git gotchas has sido atrapado?

Question

El peor que me atrapó fue con los submódulos de git. Tenía un submódulo para un proyecto en github. El proyecto no se mantuvo, y quería enviar parches, pero no pude, así que lo bifurqué. Ahora el submódulo apuntaba a la biblioteca original, y lo necesitaba para apuntar a la bifurcación. Así que eliminé el antiguo submódulo y lo reemplacé con un submódulo para el nuevo proyecto en el mismo compromiso. Resulta que esto rompió los repositorios de todos los demás. Todavía no estoy seguro de cuál es la forma correcta de manejar esta situación, pero terminé borrando el submódulo, haciendo que todos extrajeran y actualicen, y luego creé el nuevo submódulo y puse a todos a jalar y actualizar nuevamente. Tomó la mejor parte de un día darse cuenta de eso.

¿Qué han hecho otras personas para accidentalmente arruinar repositorios de git de forma no obvia, y cómo lo resolvió?

Answer 1

La barra final habitual cuando adding a submodule:

Cuando se utiliza git add en un submódulo, asegúrese de que usted no tiene una barra de colas.

> git add local/path 
    -- adds the submodule 

> git add local/path/ 
    -- adds all the files in the submodule directly into your repository, big no-no 

Answer 2

No es un gotcha, es un git cha.

Answer 3

Uno de los momentos más embarazosos con un repositorio git, aunque se trata más de sed:

vez fui haciendo una operación find ... -exec sed -i ... en un subdirectorio de mi repositorio. Lo probé sin el -i primero, me distraje, volví y logré cambiar al directorio superior en mi repositorio antes de ejecutarlo. Ahora, los archivos importantes de git son todos de solo lectura, pero sed -i de forma predeterminada barajan el archivo al renombrarlo y luego lo vuelven a escribir en el original, por lo que funciona bien en un archivo de solo lectura como los objetos de git. La sustitución no era reversible, y tuve que recuperar el repositorio clonando y obteniendo de alguien que rastreó el mío como control remoto.

Nunca pensé ni por un momento que sed funcionaría en archivos de solo lectura. Moraleja de la historia: use sed -i -c, que copia el archivo, luego intenta sobrescribir el original.

Answer 4

Publicar en un repositorio público sin darme cuenta de que mi git config user.name era incorrecto.
Eso significa que el repositorio público ahora recibe un nombre (y un correo electrónico) que preferiría no haber publicado en absoluto. Si ese repositorio se replica, ... es demasiado tarde.

Por eso prefiero tener mi user.name representada en mi git intérprete de comandos, es decir, en lugar de tener presente:

MY_HOSTNAME /c/Prog/myGitProject (master)$ 

veo esto:

MY_HOSTNAME /c/Prog/myGitProject (master) VonC $ 

Yo sé quién soy ¡desde el primer comando que escribo en esta sesión de Git bash!

Answer 5

trabajo trabajo trabajo ...

git commit 

trabajo trabajo trabajo ...

git commit 

Hm ...tiempo para integrar

git rebase -i origin/master 

¿Qué? Conflictos? Vamos a empezar de nuevo

git reset --hard origin/master 

Cry cry cry ...

---

Git permite que limpie su historia local sin remordimiento. El mayor problema es que usted son la red de seguridad.

Answer 6

1. Sólo darse cuenta de que has forgotten an entry en .gitignore una vez que tienes partidos repartidos en una carga de ramas.

2. Olvidando que git add no añade lo que no está allí ...

    
   git add . 
   git commit 
   git status 
   //hey! why didn't it commit my deletes?, Oh yeah, silly me 
   git add -u 
   git commit --amend 
   

3. Si lo hace un git branch list, se obtiene una nueva rama llamada list, pero si lo hace un git stash, te escondiste el espacio de trabajo ; de escondite, que necesidad la list si desea que la lista de ...

Más pronto, probablemente ...

Answer 7

1. trabajo trabajo trabajo
2. Stash cambia
3. lo trae última
4. Rebase
5. Obtener conflictos, repararlos
6. se olvide de "git rebase --continue"
7. Pop alijo
8. Darse cuenta de que olvidé "git rebase --continue"
9. git rebase --abort
10. Cambios guardé originalmente - pfffft, se ha ido .

Answer 8

Crear una nueva rama:

git branch new-branch 

, COMMIT, el trabajo ... Darse cuenta de todo mi trabajo es el maestro, no en la nueva sucursal.

que debería haber hecho:

git checkout -b new-branch 

Por qué no puedo hacer algo como:

git branch -c new-branch 

(c para la salida), con una opción para hacer que el comportamiento por defecto ???

Answer 9

Trabajo de trabajo. Comienza a escenificar un cambio. Observe que no quiere que todo esté comprometido. Etapa un compromiso parcial con cuidado.

Eventualmente decide que esto no está listo para la rama actual. Quiero enviar los cambios por etapas a una nueva rama temporal. Suena tan trivial conceptualmente, ¿verdad?

Google para saber cómo hacer esto. La respuesta principal dice stash, checkout -b newbranch, stash pop. Haga esto a regañadientes, preguntándose por qué no hay una manera más fácil.

Encuentra que esto borró completamente la distinción entre tus cambios por etapas y los cambios sin escena. Gracias, Git!