¿Cuál es la diferencia -práctica- entre un repositorio desnudo y no desnudo?
He estado leyendo sobre los repositorios básicos y no básicos/predeterminados en Git. No he podido entender muy bien (teóricamente) las diferencias entre ellos y por qué debería "enviar" a un repositorio simple. Aquí está el trato:
Actualmente, soy el único que trabaja en un proyecto en 3 computadoras diferentes, pero habrá más personas involucradas en él más adelante, así que estoy usando Git para el control de versiones. Clono el repositorio básico en todas las computadoras y, cuando termino mis modificaciones en una de ellas, confirmo y envío los cambios al repositorio básico. Por lo que he leído, el repositorio básico NO tiene un "árbol de trabajo", por lo que si clono el repositorio básico, no tendré un "árbol de trabajo".
Supongo que el árbol de trabajo almacena la información de confirmación, ramas, etc. del proyecto. Eso no aparecería en el repositorio simple. Por lo tanto, me parece mejor "enviar" las confirmaciones al repositorio con el árbol de trabajo.
Entonces, ¿ por qué debería utilizar el repositorio básico y por qué no? ¿Cuál es la diferencia práctica? Supongo que eso no sería beneficioso para que más personas trabajen en un proyecto.
¿Cuáles son sus métodos para este tipo de trabajo? ¿Sugerencias?
Otra diferencia entre un repositorio simple y uno no simple es que un repositorio simple no tiene un repositorio de origen remoto predeterminado:
~/Projects$ git clone --bare test bare
Initialized empty Git repository in /home/derek/Projects/bare/
~/Projects$ cd bare
~/Projects/bare$ git branch -a
* master
~/Projects/bare$ cd ..
~/Projects$ git clone test non-bare
Initialized empty Git repository in /home/derek/Projects/non-bare/.git/
~/Projects$ cd non-bare
~/Projects/non-bare$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Desde la página del manual para git clone --bare:
Además, los encabezados de las sucursales en el control remoto se copian directamente a los encabezados de las sucursales locales correspondientes, sin asignarlos a refs/remotes/origin/. Cuando se utiliza esta opción, no se crean ramas de seguimiento remoto ni las variables de configuración relacionadas.
Presumiblemente, cuando crea un repositorio básico, Git asume que el repositorio básico servirá como repositorio de origen para varios usuarios remotos, por lo que no crea el origen remoto predeterminado. Lo que esto significa es que las operaciones básicas git pully git pushno funcionarán ya que Git supone que sin un espacio de trabajo, no pretendes realizar ningún cambio en el repositorio básico:
~/Projects/bare$ git push
fatal: No destination configured to push to.
~/Projects/bare$ git pull
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
~/Projects/bare$
5 años tarde, lo sé, pero nadie respondió la pregunta:
Entonces, ¿por qué debería utilizar el repositorio básico y por qué no? ¿Cuál es la diferencia práctica? Supongo que eso no sería beneficioso para que más personas trabajen en un proyecto.
¿Cuáles son sus métodos para este tipo de trabajo? ¿Sugerencias?
Para citar directamente del libro de Loeliger/MCullough (978-1-449-31638-9, p196/7):
Un repositorio simple puede parecer de poca utilidad, pero su función es crucial: servir como punto focal autorizado para el desarrollo colaborativo. Otros desarrolladores
cloneyfetchdesde el repositorio básico ypushsus actualizaciones... si configura un repositorio en el que los desarrolladorespushrealizan cambios, debería estar vacío. En efecto, este es un caso especial de la mejor práctica más general de que un repositorio publicado debería estar vacío.
