ElUnoEquipo
¿Cuál es la diferencia entre git init y git init --bare? Descubrí que muchas publicaciones de blog requieren --bare para su servidor Git?
Desde la página de manualdecía:
--bareCree un repositorio desnudo. Si el entorno GIT_DIR no está configurado, se configura en el directorio de trabajo actual
Pero, ¿qué significa realmente? ¿Se requiere tener --bare para la configuración del servidor Git?
adam dimitruk
Esta variante crea un repositorio con un directorio de trabajo para que pueda trabajar (git clone). Después de crearlo, verá que el directorio contiene un .git carpeta donde va el historial y toda la fontanería de git. Trabajas en el nivel donde el .git carpeta es.
La otra variante crea un repositorio sin un directorio de trabajo (git clone --bare). No obtienes un directorio donde puedas trabajar. Todo en el directorio es ahora lo que estaba contenido en el .git carpeta en el caso anterior.
La necesidad de repositorios git sin un directorio de trabajo es el hecho de que puede enviar ramas y no administra en qué está trabajando alguien. Todavía puede enviar a un repositorio que no está vacío, pero será rechazado ya que potencialmente puede mover una rama en la que alguien está trabajando en ese directorio de trabajo.
Entonces, en un proyecto sin carpeta de trabajo, solo puede ver los objetos tal como los almacena git. Se comprimen, serializan y almacenan bajo el SHA1 (un hash) de su contenido. Para obtener un objeto en un repositorio simple, debe git show y luego especifique el sha1 del objeto que desea ver. No verá una estructura como la que se ve en su proyecto.
Los repositorios desnudos suelen ser repositorios centrales a los que todo el mundo traslada su trabajo. No hay necesidad de manipular el trabajo real. Es una forma de sincronizar los esfuerzos entre varias personas. No podrá ver directamente los archivos de su proyecto.
Es posible que no necesite ningún repositorio básico si es el único que trabaja en el proyecto o si no desea/necesita un repositorio “lógicamente central”. uno preferiría git pull desde los otros repositorios en ese caso. Esto evita las objeciones que tiene git cuando empuja a repositorios no desnudos.
Espero que esto ayude
Mantenerse lostirar a de esta línea – Uno preferiría git pull del otro… 🙂
– Arup Rakshit
09/06/2014 a las 12:30
Encuentro esta respuesta muy poco clara y confusa. Algunas de las razones están aquí: meta.stackoverflow.com/questions/339837/…
– Marko Avlijas
19 de diciembre de 2016 a las 11:32
Bare repositories are usually central repositories where everyone moves their work to. ¿Quiere decir que un repositorio simple es la fuente desde la cual otros colaboradores del proyecto pueden clonar un proyecto? Es decir, los colaboradores tratan esto como el remote?
– Minh Tran
6 de febrero de 2019 a las 16:47
@MinhTran: por lo general, sí. Pero tenga en cuenta que cuando obtiene confirmaciones desde algún repositorio, es irrelevante para usted si ese otro repositorio es uno desnudo, o no. Al empujar sus confirmaciones para ese repositorio, su desnudez o falta de ella, puede volverse relevante para usted.
– torek
6 de diciembre de 2020 a las 8:37
@torek Compuse mi comentario antes de saber que los repositorios simples se pueden usar como un repositorio remoto. Mi empresa quería mantener el código de desarrollo interno, así que necesitaba una forma de compartir mi código en un servidor de archivos. La solución fue configurar repositorios simples y usarlos como un repositorio remoto. Donde normalmente empujaría a una URL de repositorio remoto, presioné a un directorio de repositorio simple en el sistema de archivos.
– Minh Tran
6 de diciembre de 2020 a las 21:22
Duncan
Un repositorio simple es un repositorio de git sin una copia de trabajo, por lo tanto, el contenido de .git es de nivel superior para ese directorio.
Utilice un repositorio básico para trabajar localmente y un repositorio básico como servidor/concentrador central para compartir sus cambios con otras personas. Por ejemplo, cuando crea un repositorio en github.com, se crea como un repositorio simple.
Entonces, en tu computadora:
git init
touch README
git add README
git commit -m "initial commit"
en el servidor:
cd /srv/git/project
git init --bare
Luego, en el cliente, presionas:
git push username@server:/srv/git/project master
Luego puede ahorrarse la escritura agregándolo como control remoto.
El repositorio en el lado del servidor obtendrá confirmaciones a través de extracción y inserción, y no editando archivos y luego comprometiéndolos en la máquina del servidor, por lo tanto, es un repositorio simple.
Puede empujar a un repositorio que no es un repositorio simple, y git descubrirá que hay un repositorio .git allí, pero como la mayoría de los repositorios “hub” no necesitan una copia de trabajo, es normal usar un repositorio simple para y recomendado ya que no tiene sentido tener una copia de trabajo en este tipo de repositorios.
Sin embargo, si empujas a un repositorio no vacío, estás haciendo que la copia de trabajo sea inconsistente y git te advertirá:
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
Puede omitir esta advertencia. Pero la configuración recomendada es: use un repositorio no básico para trabajar localmente y un repositorio básico como un concentrador o servidor central para enviar y extraer.
Si desea compartir el trabajo directamente con la copia de trabajo de otro desarrollador, puede extraer de los demás repositorios en lugar de enviarlos.
si quiero trabajar mi proyecto en el servidor git, entonces no es necesario tener la opción –bare, ¿no es así?
– El Equipo Único
22 de octubre de 2011 a las 17:18
Utiliza bare para el repositorio remoto, no para el local.
– duncan
22 de octubre de 2011 a las 17:51
Es un ratito, pero aquí otra pregunta. Si tenemos un repositorio remoto simple, cualquier desarrollador puede presionarlo, y el repositorio es “central”. Pero si trabajamos sin un repositorio básico, los desarrolladores solo deben extraer información entre ellos, pero nunca empujarse. El último escenario es bueno, si solo hay 2 copias de trabajo del repositorio (también conocido como repositorios locales). ¿Es esto correcto?
– Asturias
3 mayo 2012 a las 13:34
Cuando leí esta pregunta hace algún tiempo, todo me resultaba confuso. Acabo de empezar a usar git y existen estas copias de trabajo (que no significaban nada en ese momento). Intentaré explicar esto desde la perspectiva del tipo, que acaba de empezar a usar git sin tener idea de la terminología.
Un buen ejemplo de las diferencias se puede describir de la siguiente manera:
--bare Te da solo un lugar de almacenamiento (no se puede desarrollar allí). Sin --bare te da la capacidad de desarrollar allí (y tener un lugar de almacenamiento).
git init crea un repositorio git desde su directorio actual. Agrega la carpeta .git dentro de él y hace posible iniciar su historial de revisión.
git init --bare también crea un repositorio, pero no tiene el directorio de trabajo. Esto significa que no puede editar archivos, confirmar sus cambios, agregar nuevos archivos en ese repositorio.
Cuándo --bare puede ser útil? Usted y algunos otros muchachos están trabajando en el proyecto y usan git . Alojaste el proyecto en algún servidor (amazon ec2). Cada uno de ustedes tiene su propia máquina y empuja su código en ec2. Ninguno de ustedes realmente desarrolla nada en ec2 (usted usa sus máquinas), simplemente presiona su código. Entonces tus ec2 es solo un almacenamiento para todo su código y debe crearse como --bare y todas tus máquinas sin --bare (lo más probable es que solo uno, y otro simplemente clonará todo). El flujo de trabajo se ve así:
Entonces, ¿podríamos decir que usando un repositorio –bare podemos crear un tipo de arquitectura cliente-servidor como lo hace subversion?
– Emiliano Sangoi
24 de diciembre de 2015 a las 16:02
@EmilianoSangoi ¡Cuidado con lo que dices o te acusarán de herejía! jajaja
– JuanK
26 de abril de 2021 a las 17:57
Un repositorio Git predeterminado asume que lo usará como su directorio de trabajo. Por lo general, cuando está en un servidor, no necesita tener un directorio de trabajo. Solo el repositorio. En este caso, debe utilizar el --bare opción.
Un repositorio no desnudo es el valor predeterminado. Es lo que se crea cuando corres git inito lo que obtienes cuando clonas (sin la bare opción) desde un servidor.
Cuando trabaja con un repositorio como este, puede ver y editar todos los archivos que están en el repositorio. Cuando interactúa con el repositorio, por ejemplo, al realizar un cambio, Git almacena sus cambios en un directorio oculto llamado .git.
Cuando tiene un servidor git, no es necesario que haya copias de trabajo de los archivos. Todo lo que necesita son los datos de Git que están almacenados en .git. Un repositorio desnudo es exactamente el .git directorio, sin un área de trabajo para modificar y enviar archivos.
Cuando clonas desde un servidor, Git tiene toda la información que necesita en el .git directorio para crear su copia de trabajo.
Otra diferencia entre los repositorios –bare y Working Tree es que en el primer caso no se almacenan confirmaciones perdidas, sino solo confirmaciones que pertenecen a una pista de bifurcación se almacenan. Por otro lado, Working Tree mantiene todas las confirmaciones para siempre. Vea abajo…
Creé el primer repositorio (nombre: git-desnudo) con git init --bare. es el servidor Está en el lado izquierdo, donde no hay sucursales remotas porque este es el repositorio remoto en sí.
Creé el segundo repositorio (nombre: git-árbol-de-trabajo) con git clone desde el principio. Está a la derecha. Tiene sucursales locales vinculadas a sucursales remotas.
(Los textos ‘primero’, ‘segundo’, ‘tercero’, ‘cuarto’, ‘alfa’, ‘beta’ y ‘delta’ son los comentarios de confirmación. Los nombres ‘maestro’ y ‘griego’ son nombres de rama).
Ahora eliminaré la rama llamada ‘griego’ tanto en git-desnudo (mando: git push --delete origin greek) y localmente en git-árbol-de-trabajo (mando: git branch -D greek). Así es como se ve el árbol:
los git-desnudo El repositorio elimina tanto la rama como todos los comits a los que se hace referencia. En la imagen vemos que su árbol fue reducido por este motivo.
Por otro lado, el git-árbol-de-trabajo El repositorio, que es equivalente a un repositorio local de uso común, no elimina las confirmaciones, que ahora solo pueden ser referenciadas directamente por su hash con un git checkout 7fa897b7 mando. Por eso su árbol no tiene su estructura modificada.
EN BREVE: Las confirmaciones nunca se incluyen árbol de trabajo repositorios, pero se eliminan en desnudo repositorios
En términos prácticos, solo puede recuperar una rama eliminada en el servidor si existe en un repositorio local.
Pero es muy extraño que el tamaño de la desnudo el repositorio no disminuye en tamaño de disco después de eliminar una rama remota. Es decir, los archivos todavía están allí de alguna manera. Para volcar el repositorio eliminando lo que ya no se referencia o lo que nunca se puede referenciar (el último caso) use el git gc --prune mando