# Colaborando com Git

Git funciona localmente. Commits, branches, logs estão gravados no
repositório local. Para colaborar com outros projetos, precisamos
publicar e ter acesso a repositórios públicos.

É possível publicar através de vários protocolos. Além de um diretório
local, uma das formas mais simples é utilizar SSH, já que independe de
outra configuração e permite escrita. HTTP é uma boa opção somente
leitura para repositórios públicos, já que não exige credenciais para
acesso. A outra opção é o protocolo próprio do Git, através do git
daemon.

## Clonando Repositórios

Para criar um novo repositório a partir de um repositório publicado,
usamos o comando git clone.

	~/$ git clone /home/user2/project
	Cloning into 'project'...
	done.
	~/$ cd project
	~/project$ ls -a
	.  ..  .git  README
	~/project$ 

Quando um repositório é clonado, temos uma cópia local das referências
deste repositório. O repositório é registrado com um nome, sendo origin
o nome padrão, e as referências a seus branches são prefixadas com este
nome e uma barra. Para visualizar estes branches remotos, utilizamos a
opção -r do comando git branch.

	~/project$ git branch -r
	  origin/HEAD -> origin/master
	  origin/master
	~/project$ 

Note que o HEAD do repositório remoto aponta para o branch remoto
chamado master. O HEAD remoto é utilizado para criar um novo branch
local quando o repositório é clonado.

	~/project$ git branch
	* master
	~/project$ 

## Remotes

Com Git, é possível colaborar com mais de um repositório remoto. A lista
de repositórios rastreados, com seus nomes e URLs fica no arquivo de
configuração do repositório, ou seja, $REPODIR/.git/config.

Para manipular esta lista, o comando git remote pode ser útil. É
possível listar, adicionar, remover, renomear repositórios remotos.

Ao clonar um repositório, o remoto origin já é criado. Este é o nome
padrão para comandos que aceitam um remoto como parâmetro, mas permitem
que seja omitido, assumindo o remoto origin.

	~/project$ git remote
	origin
	~/project$ 

Para adicionar um novo remoto, usamos o subcomando add, passando um nome
e uma URL como parâmetros.

	~/project$ git remote add git://alice.example.com/project.git/
	~/project$ git remote show
	alice
	origin
	~/project$ git remote show -n alice
	* remote alice
	  Fetch URL: git://alice.example.com/project.git/
	  Push  URL: git://alice.example.com/project.git/
	  HEAD branch: (not queried)
	  Local ref configured for 'git push' (status not queried):
	    (matching) pushes to (matching)
	~/project$ 

Ao adicionar um novo repositório remoto, apenas acrescentamos este
repositório ao nosso arquivo de configuração. Não fazemos nenhum
download dos seus branches e commits remotos. A opção -n do subcomando
show evita buscar dados remotamente, que utilizaria a rede.

Note que temos duas URLs, uma para fetch e outra para push, que veremos
logo a seguir o que significam. Também temos o branch para qual o HEAD
do remoto aponta. Neste caso, como o repositório não foi acessado, não
temos esta informação. E a configuração para o push, que veremos logo a
seguir, fará atualização de branches que se casem.

Para remover um repositório remoto, utilizamos o subcomando rm, e pare
renomear, o subcomando rename.

	~/project$ git remote rename alice aliceS
	~/project$ git remote show
	aliceS
	origin
	~/project$ git remote rm aliceS
	~/project$ 

## Fazendo atualizações

Após adicionar um remoto, queremos fazer o download dos branches e
commits remotos. Um dos comandos que pode ser utilizado é git fetch.

	~/project$ git fetch alice
	From git://alice.example.com/project.git/
	 * [new branch]      master     -> alice/master
	 * [new branch]      shell      -> alice/shell
	~/project$ git branch -r
	  alice/master
	  alice/shell
	  origin/HEAD -> origin/master
	  origin/devel
	  origin/master
	~/project$ 

Note que ao realizar o fetch, diferente do clone, não é criada uma
referência ao HEAD do repositório remoto. Tampouco, é criado um branch
local, ou feito um checkout. As referências, no entanto, são escritas
localmente, de tal forma que é possível investigar os commits dos
branches remotos sem novo acesso à rede.

Como o acesso à rede não é feito a cada comando, novas atualizações
precisam ser feitas quando o repositório remoto é atualizado e deseja-se
investigar novos branches ou novos commits. Além de git fetch, pode ser
utilizado git remote update.

	~/project$ git remote update
	Fetching origin
	Fetching alice
	From /home/cascardo/git/ff/project
	 * [new branch]      devel      -> alice/devel
	~/project$ 

Veja que um novo branch foi atualizado.

## Branches remotos

Agora que temos uma lista de branches remotos, podemos manipulá-los como
branches locais, usando git log, git diff, entre outros comandos.
Podemos fazer um checkout de um branch remoto, criando um branch local.

	~/project$ git checkout -b shell alice/shell
	Branch shell set up to track remote branch shell from alice.
	Switched to a new branch 'shell'
	~/project$ git branch -vv
	  master 033d4b8 [origin/master] Acrescenta lista de arquivos a serem ignorados.
	* shell  a5cb5bb [alice/shell] Implementação de hello em shell script.
	~/project$ 

A opção -vv de git branch mostra o commit ID, o sumário do commit, e o
branch remoto que é rastreado pelo branch local. O rastreamento de um
branch local é importante para comandos como git push e git pull, que
veremos logo mais.

## Publicando um repositório

Vimos como trabalhar com um repositório remoto, obtendo seus commits
para trablharmos localmente. No entanto, o caminho reverso é necessário
para publicarmos os commits locais para que outros possam trabalhar com
eles.

Há várias formas de fazê-lo. Veremos aqui algumas delas, utilizando um
host próprio, que seja acessível ao público alvo, através de SSH, HTTP
ou git daemon.

Publicar através de SSH é simples de ser feito, mas tem algumas
implicações. Entre elas é o acesso exigido a um shell no host para os
usuários, dificultando acesso anônimo e criando um novo problema de
segurança a ser resolvido. A outra implicação é que o acesso por
múltiplos usuários a um mesmo repositório exige um cuidado especial para
evitar problemas de permissão quando um usuário publica novos commits e
outros objetos. Há algumas soluções que resolvem alguns desses
problemas, criando um shell e um usuário especial para uso dedicado a
repositórios Git. Veremos, no entanto, apenas a solução mais comum, que
não exige outro software instalado no host, além de Git.

Uma excelente forma de utilizar a publicação via SSH é disponibilizá-la
de forma somente leitura através de outros métodos, e ter um único
usuário que possa atualizá-lo, o que resolve vários dos problemas já
mencionados.