La siguiente minireceta muestra cómo crear un repositorio para proyectos en GIT (servidor) y cómo gestionarlo desde la parte cliente.
Nótese que en lugar de especificar el nombre del proyecto en cada comando, usaré una variable de entorno "$PROJECT" de forma que se puedan reutilizar los comandos rápidamente para diferentes proyectos.
En el equipo que hará el rol de servidor GIT:
Como usuario root, empezamos instalando el software y creando el "home" para ubicar los repositorios (en git cada proyecto debe de ir en un único repositorio):
# apt-get install git git-doc # mkdir /var/git # adduser git --home /var/git/ # chown git:git -R /var/git/ # su - git
Después, como usuario "git", autorizamos el acceso vía SSH con las claves RSA que accederán sin password:
$ mkdir .ssh $ chmod 0700 .ssh $ cd .ssh $ vim authorized_keys (añadir las claves extraídas de id_rsa.pub aquí) $ chmod 0600 authorized_keys $ exit
Vamos a ver cómo versionar un proyecto en GIT. Si lo teníamos alojado en subversion, con el método que vamos a ver perderíamos el histórico del proyecto (empezaríamos un nuevo historial de cambios).
En el equipo que hará el rol de servidor GIT:
$ export PROJECT="the_project" $ mkdir ${PROJECT}.git $ cd ${PROJECT}.git $ git --bare init
Nótese que el directorio en el servidor suele tener por convención el sufijo .git. Esto es normal, y al hacer el "clone" en los clientes este sufijo no aparece.
En el equipo (uno o más de uno) cliente GIT (es decir, en los equipos donde desarrollaremos), haremos lo siguiente:
Lo primero que haremos será instalar git:
$ sudo apt-get install git git-doc gitk
Después estableceremos las siguientes variables globales y aliases para nuestra máquina cliente git:
git config --global user.name "Nombre Apellidos" git config --global user.email "usuario@dominio.com" git config --global core.editor vim git config --global merge.tool vimdiff git config --global alias.unstage 'reset HEAD --' git config --global alias.last 'log -1 HEAD' git config --global alias.graphlog 'log --pretty=oneline --graph' git config --global alias.visual '!gitk'
Concretamente, el flag –global provoca que estas directivas se creen dentro de un fichero .gitconfig en el directorio $HOME de usuario.
Las anteriores variables son globales para todos los proyectos, pero podemos establecer algún valor específico para un proyecto (como cambiar el email, o un alias) si dentro de un proyecto ya inicializado realizamos el "git config" correspondiente sin el flag –global. Podemos listar las variables locales/globales en cualquier momento con "git config –list" (dentro o fuera del repositorio veremos la diferencia entre globales y locales).
En el equipo cliente, vamos al directorio del proyecto y creamos un repositorio local en él. Si tenemos "restos" de subversion, los eliminamos:
$ export PROJECT="the_project" $ cd /var/code/$PROJECT $ rm -rf .svn $ git init
Ahora ya tenemos un repositorio "inicializado" en el directorio del proyecto (pero sin ficheros dentro). Añadimos todos los ficheros del proyecto:
$ git add .
Adicionalmente, creamos un fichero README descriptivo (es recomendado hacerlo en todos los proyectos) y lo añadimos:
$ vim README $ git add README
También se recomienda crear un fichero .gitignore que contenga expresiones regulares (de ficheros y directorios que acaben en /), comentarios, etc. Estas expresiones regulares identificarán ficheros que git ignorará para el control de versiones cuando hagamos "adds" recursivos:
$ cat .gitignore # Ficheros a ser ignorados por git: *.[oa] # librerías y ficheros objeto build/ # Directorio build/ y sus subdirectorios target/ dist/ Debug/ Release/ /TODO # fichero TODO en el raiz pero no los TODOs en subdirectorios *~ # backups creados por editores $ git add .gitignore
También podemos establecer ignores globales a todos los proyectos en un fichero de nombre .gitignore en el $HOME del usuario.
Hacemos el primer commit a nuestro repositorio LOCAL (es decir, dentro del subdirectorio .git del directorio del proyecto):
$ git commit -m "Commit inicial del proyecto"
Y ahora subimos los datos al repositorio remoto, para lo cual añadimos el repositorio remoto:
$ git remote add origin ssh://git@servidor.com/var/git/${PROJECT}.git $ git remote -v (debe de aparecer el nuevo directorio remoto) $ git push origin master
A partir de este momento, ya podremos subir los cambios simplemente con git push ya que el anterior comando crea la rama origin/master y hace equivalente localmente "master" con "origin/master" para el push.
Para comprobar que la subida inicial del proyecto ha sido correcta, se recomienda "clonar" una copia del mismo desde el repositorio remoto en un directorio de prueba temporal, siguiendo el siguiente punto/apartado.
Ahora, para "descargar" una copia del proyecto en otro equipo de desarrollo, hacemos lo siguiente:
$ cd /var/code/ $ export PROJECT="the_project" $ git clone ssh://git@servidor.com/var/git/${PROJECT}.git ${PROJECT}
Esto creará el directorio "the_project" ya versionado.
cd PROJECT (execute from project directory) git status -> show files different between the working dir, index and HEAD git diff -> show differences between working directory and staging area git diff --cached -> show differences between staging area and HEAD git fetch -> download changes from remote repo git add file -> stage file git log -> log report (accepts: -p -N = last N lines --stat --pretty=oneline --pretty=oneline --graph --since=DATE like 2.weeks, "2013-03-01", etc. --before=DATE --author=NAME git commit -> upload changes to local repo. Add -m "message" to define changelog. git commit --amend -> Correct (replace) last commit. git diff -> diff (working-dir vs stage-area) git diff --staged -> diff (stage-area vs last-commit) git rm file_or_dir -> remove local file or dir. Escape characters that could be expanded by the shell. Example: $ git rm log/\*.log git mv filedir1 filedir2 -> move/rename remote files/dirs gitk -> visual history git remote -v -> List remote repositories git push master origin -> Push changes to remote server git remote add ssh://user@server:port/path/repodir -> Add remote repository