Los repositorios en Git son una instantánea de la carpeta en la que está trabajando en su proyecto. Puede realizar un seguimiento del progreso y los cambios realizados en el proyecto mediante confirmaciones y también revertir los cambios si no son satisfactorios.
Los repositorios se pueden dividir en dos tipos según el uso en un servidor. Estos son:
- Repositorios no desnudos
- Repositorios desnudos
¿Qué es un repositorio no desnudo?
Un repositorio git no básico o predeterminado tiene una carpeta .git , que es la columna vertebral del repositorio donde se almacenan todos los archivos importantes para el seguimiento de los cambios en las carpetas. Almacena los hash de los commits realizados en las ramas y un archivo donde se almacena el hash del último commit.
La estructura de archivos del repositorio predeterminado debería verse así:
-- Default_Repo*
|-- .git*
| |-- hooks*
| |-- info*
| |-- logs*
| |-- objects*
| |-- refs*
| |-- COMMIT_EDITMSG
| |-- config
| |-- description
| |-- HEAD
| |-- index
|-- example.txt
*: Folders
Como puede ver, la carpeta .git contiene todos los archivos necesarios para rastrear la carpeta del proyecto. El repositorio predeterminado siempre se usa para los repositorios locales.
¿Qué es un repositorio desnudo?
Un repositorio simple es lo mismo que el predeterminado, pero no se pueden realizar confirmaciones en un repositorio simple. Un repositorio simple no puede rastrear los cambios realizados en los proyectos, ya que no tiene un árbol de trabajo. Un árbol de trabajo es un directorio en el que residen todos los archivos/subdirectorios del proyecto. El repositorio básico es esencialmente una carpeta .git con una carpeta específica donde residen todos los archivos del proyecto.
Prácticamente hablando, todo en el repositorio excepto .gites una parte del árbol de trabajo. Para crear un repositorio simple, navegue hasta el directorio elegido en bash (para usuarios de Linux) o en el símbolo del sistema (para usuarios de Windows) y escriba:
>mkdir FileName.git
>cd FileName.git
>git init –bare
La estructura de archivos del repositorio básico debería verse así:
-- BareRepo.git*
|-- hooks*
|-- info*
|-- logs*
|-- objects*
|-- refs*
|-- COMMIT_EDITMSG
|-- config
|-- description
|-- HEAD
|-- index
*: Folders
Nota: Esta es exactamente la misma estructura de archivos de la carpeta .git en el repositorio no desnudo
Es importante tener en cuenta que todos los repositorios desnudos tienen la extensión .git (por ejemplo, observe BareRepo.git). Dado que no puede confirmar ni realizar cambios, los repositorios básicos son bastante inútiles por sí solos. Pero entonces, ¿por qué existe? Cuando las personas colaboran para trabajar en un proyecto, necesitan un repositorio central donde se almacenen todos los cambios registrados y se evite cualquier conflicto entre las versiones del proyecto en las computadoras de otros. Un repositorio central también significa que cualquier colaborador nuevo puede clonar el repositorio en uno local sin obtener cambios no guardados o trabajos conflictivos de otros (en resumen, sin problemas). Se suponía estrictamente que un depósito central era algo así como un depósito de referencia.
Esto requiere que uno use un repositorio remoto como uno central, e inicialmente, solo los repositorios Bare podrían usarse como repositorios remotos. Con los últimos cambios en git, los repositorios centrales no necesitan estar vacíos, por lo tanto, no mucha gente lo sabe correctamente.
Las únicas operaciones posibles en Bare Repository son Push o Cloning.
Uso de un repositorio simple
Un repositorio simple está vinculado con un repositorio local, por lo tanto, los archivos en .git del repositorio local deben coincidir con los archivos en el repositorio simple. Primero, cree un repositorio simple (consulte la sección para el fragmento de código).
Luego, cree una carpeta de repositorio local y clone el repositorio simple:
>cd C:/Users/example/repositories
>git clone C:/Users/example/BareRepo.git
Cloning into 'BareRepo'...
warning: You appear to have cloned an empty repository.
done.
No te preocupes por la advertencia. El repositorio clonado tendrá el mismo nombre que el repositorio básico, navegue a esa carpeta y agregue archivos de proyecto y confirme los cambios. Luego, envíe los cambios al repositorio básico:
>git add *
>git commit -m “First commit”
[master (root-commit) ffdf43f] First Commit
1 file changed, 1 insertion(+)
create mode 100644 example.txt
>git push c:/users/example/BareRepo.git
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 293 bytes | 97.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To c:/users/example /BareRepo.git
* [new branch] master -> master
Y, por lo tanto, su repositorio local se ha vinculado al repositorio básico. En caso de que ya tenga algunos archivos en el directorio del proyecto, inicialice directamente la carpeta del proyecto como un repositorio de git, luego envíe sus cambios a un repositorio básico (asegúrese de que el repositorio básico no esté vinculado a ningún otro proyecto o que se haya creado recientemente). Otra forma es clonar el repositorio de su proyecto de trabajo en uno simple:
>cd “Central Repositories”
>git clone –bare ../../…./Default_Repo
Cloning into bare repository 'Default_Repo.git'...
done.
¿Por qué solo se utiliza Bare Repository como repositorio central para sincronizar el trabajo?
Los repositorios centrales usan repositorios simples solo porque git no le permite enviar a un repositorio no simple ya que el árbol de trabajo se volverá inconsistente .
Para demostrar por qué no puede enviar a un repositorio no desnudo:
>cd C:/Users/example/repositories
>mkdir RepoTest
>cd RepoTest
>git init
Initialized empty Git repository in C:/Users/example/repositories/RepoTest/.git/
>cd ../BareRepo
>git push ../RepoTest
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 293 bytes | 146.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
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: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
remote:
remote: You can set the 'receive.denyCurrentBranch' configuration variable
remote: to 'ignore' or 'warn' in the remote repository to allow pushing into
remote: its current branch; however, this is not recommended unless you
remote: arranged to update its work tree to match what you pushed in some
remote: other way.
remote:
remote: To squelch this message and still keep the default behaviour, set
remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ../RepoTest
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '../RepoTest'
Pero si aún quiere ser obstinado al respecto, puede leer la advertencia e ir al repositorio no desnudo donde desea presionar y configurar receive.denyCurrentBranch para ignorar y luego presionar los cambios.
>cd ../RepoTest
>git config receive.denyCurrentBranch ignore
>cd ../Default_Repo
>git push ../RepoTest
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 293 bytes | 146.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../RepoTest
* [new branch] master -> master
Pero, usar esto le dará más problemas, ya que sigue presionando al repositorio remoto, notará que solo los puntos de cabeza de confirmación siguen cambiando (junto con otros archivos en .git), pero su árbol de trabajo seguirá siendo el mismo. La única forma de eliminar la inconsistencia del índice y el árbol de trabajo es usando el comando:
>git reset –hard
A menos que desee hacer esto cada vez que envíe cambios al repositorio remoto, se recomienda utilizar un repositorio simple.
Un repositorio simple ocupa mucho menos espacio para almacenar la misma información junto con los cambios registrados que un repositorio no simple. Por lo tanto, su consumo de almacenamiento es el más eficiente. Por lo tanto, solo un repositorio simple es adecuado para servir como repositorio remoto o central.