Inicializar repositorio y agregar remoto

1. Ir al directorio raíz en don donde se encuentra el código a versionar

2. Inicializar un repositorio (repo) local en el mismo directorio con:

$ git init

3. Agregar los archivos existentes al reposoitorio para empezar tracking:

$ git add .

4. Hacer commit (-m ‘Mensaje incluido en commit’:

$ git commit -m 'initial commit of full repository'

5. Crear un repositorio en BitBucket indicando que se tiene un projecto existente y utilizando el link
que aperece para conectar al remoto ejecutar:

$ git remote add origin <LinkToRepo>

Hacer un push de todo hacia el repositorio remoto (remote) de Btibucket:

$ git push -u origin --all

Estado de Repositorio

Se usa el comando git status para evaluar el estado del repositorio en la rama actual:

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean

Agregar archivos y cambios

Después de haber hecho cambios en, o agregado/borrado, archivos se deben preparar para
poder hacer commit.
Para agregar todos los cambios hechos se utiliza el comando:

$ git add -A

(-A y --all son equivalentes)

-u = Agrega los cambios a archivos actualmente en tracking y el borrado de archivos al próximo

commit. No incluye archivos nuevos

. = Incluye archivos nuevos o cambiados en el próximo commit. No incluye le borrado de

archivos.
Un ejemplo de esto, se tiene un proyecto al cual se ha agregado el archivo “SomeClass.java”
entonces:

Unstage un archivo

Para evitar que los cambios a un archivo o archivos agregados sean incluidos en el próximo
commit se utiliza el comando:

$ git reset HEAD <nombre_archivo>

Hacer un commit

Solo los cambios/archivos que han sido “staged” con el comando git add se incluyen en
próximo commit, el cual se realiza con:

$ git commit -m ‘Mensaje’

Donde con -m se debe agregar un mensaje al commit.

--amend = Edit the commit message associated with the most recent commit
--amend <File_1> <File_2> . . . <File_n> = redo the previous commit and include changes to
specified files
Para hacer commit solo de los cambios a un archive especifico:

$ git commit FileName –m “Message Text”

Ver el Historial de Commits

Para ver los commits que se han realizado se utiliza:

$ git log -<n>

Donde -<n> es opcional, se muestran los n commits mas recientes (sustiuir <n> por un numero)

$ git log -2 entonces mostraría los últimos dos commits hechos,y quien los hizo.

Hacer Push de Los Cambios al Remote

Para enviar los commits hechos al servidor del repositorio y actualizar el “remote”, se utiliza el
comando:

$ git push [<remoteName> <branchName>]

Donde el comadno

$ git push

Envia todos los commits para todas las ramas al remote, no se toman en cuenta las ramas que
no son comunes al repositorio local y el remoto.

Esto ultimo ocurre cuando se ejecuta por primera vez para cada rama lo siguiente:

$ git push remoteName localBranchName

Esto actualiza el remote con los commits de la rama especificada.
(La única excepción es la rama master, al clonar el repositorio remoto, se hace común al local
también)
Entonces para enviar los commits solo nuestra la rama master se llama
$ git push origin master

Se observa que el repositorio remoto se actualiza con el commit local, incluyendo su mensaje, lo
que significa que nuestro archivo “SomeClass.java” fue agregado exitosamente al remote.
IMPORTANTE: Si alguien más hizo push a la rama master, tendrá que hacer fetch de los
cambios incorporados por la otro persona, antes de hacer push de los suyos.

Fetching

Para obtener toda la data de un remote se utliza:

$ git fetch [remote-name]

Esto recupera toda la informacion referente al repositorio remote, incluyende referencias a

ramas de ese ‘remote’ y las crea localmente
Sin embargo, esto no adiciona los cambios automáticamente a la rama local en que se está,
hay que hacer un merge manual de la rama remota cuyos cambios se quieren adicionar, si el
remote tiene varias ramas, hay que especificar con que rama del remote se va a hacer merge
Merging

$ git merge RemoteName/BranchName

Pulling

Si la rama actual está configurada para ser tracking de una remota (esto ocurre automática
mente con el master local y del remoto al clonar, o al hacer fetch de todo el remote), basta
hacer git pull al estar en la rama local para que se descargue la data de la rama remota, y git
intente hacer merge del remote branch al local.

Para obtener información de que ramas del remote se está haciendo tracking, se puede
llamar al comando:

$ git remote show remoteName

Donde remoteName es el nombre del remote (en nuestros ejemplos es origin el nombre, el cual
es por defecto)
Crear un Branch local
Para crear una rama o branch basta con llamar al comando:

$ git branch newBranch

Donde newBranch es el nombre de la rama que se va a crear, y esta rama tiene el contenido
que la rama actual tenía al momento de su creación.

Colocarse en una Rama

Para cambiar de una rama a otra se llama al comando

$ git checkout newBranch

De esta manera el puntero de la rama actual cambia a newBranch

Note que hasta ahora hemos estado trabajando en la rama master (es el nombre que git le da a
laprimera rama creada por defecto) y al hacer git checkout test nos colocamos en la rama de
ese nombre, esto se observa en el texto en azul en la ventana.
Ahora los cambios y commits de ‘test’ no afectarán a ‘master’ hasta se haga un merge local de
‘master’ con ‘test’

Borrar una Rama

$ git push origin --delete <branch_name> #Borra una rama remota
$ git branch -d <branch_name> #Borra una local
Merging Local

Para adicionar los cambios de una rama a otra, nos colocamos primero en la rama a la que
queremos adicionar cambios de otra:

$ git checkout rama1

y llamamos al comando:

$ git merge rama2

Esto hace un merge de la información de la rama1 a la rama2
Ejemplo:

Conflictos con Merge

Si se hacen cambios en el mismo archivo, en dos ramas diferentes, al tratar de hacer merge de
una rama con la otra, ocurrirá un conflicto.
Por ejemplo, si se cambió una línea del arcihvo ‘SomeClass.java’ en una rama ‘test’, se hizó
commit. Luego se cambió a la rama master, se cambia el mismo grupo de líneas en
‘SomeClass.java’ y se hace commit, al hacer merge de test con mater ocurre:

Git indica el o los archivos donde no pudo hacer merging de manera automática

Para resolver los conflicto hay que manualmente editar el archivo donde ocurre el conflicto,
donde se apreciará los siguiente:

La parte superior indica como estaba el archivo en la rama

actual (‘master’ en este caso, HEAD indica que es la rama
actual)

En la parte inferior como estaba en el archivo de la rama con

la que se trata de hacer merge (‘test’ en este caso)
El proceso de merge se pausa mientras Git espera que resolvamos el conflicto. Por lo cual en
cualquier momento podemos llamar a git status para obtener más información del conflicto

Git nos indica que ambos archivos se modificaron, como mencionamos previamente.
Para resolver esto hay reemplazar todo el bloque con el contenido de alguno del os archivos,
por ejemplo, usaremos los cambios en ‘test’ (puede ser hasta una mezcla)

Una vez resuelto el conflicto hay que agregar (o hacer staging) de los cambios con

git add .

Verificamos que los conflictos estén resueltos:

Y se hace commit de los cambios:

Y luego hacer el push a las ramas remotas correspondientes.