Dicas Git da semana: adicionando conteúdo e configurando um repositório compartilhado

Nesta semana, serão dadas duas dicas. Uma delas aborda a adição de conteúdo, e a outra, a configuração de um repositório compartilhado.

Identifique-se

A primeira coisa que você precisa fazer é dizer ao Git quem você é, de modo que qualquer commit subsequente grave sua autoria de forma adequada. É possível fazer isso em uma base de repositório por repositório, mas é geralmente o caso de configurar isso em um nível global. (Para configurar em um nível por projeto, execute dentro de um repositório e sem a opção –global.)

$ git config --global user.name Alex Blewitt
$ git config --global user.email alex.blewitt@gmail.com

Note que o e-mail distingue maiúsculas de minúsculas, e alguns sistemas serão exigentes sobre a correspondência exata no processo. Se configurá-lo no nível global, então você não precisa fazer esse passo novamente.

Adicionando conteúdo

A adição de conteúdo a um repositório Git é feita em duas etapas: em primeiro lugar, acrescentando o conteúdo em si e, em segundo, comitando o conjunto de alterações.

Como outros sistemas de controle de versão, você precisa adicionar conteúdo em um repositório para informar o que está sob o controle do repositório. Para fazer isso com o Git, você pode usar git add para adicionar um ou mais arquivos sob controle do Git:

$ git add file.c file.h docs/

Uma vez que os arquivos tiverem sido adicionados, a revisão pode ser comitada para o repositório com git commit:

$ git commit

Quando um conjunto de alterações é comitado, você tem a oportunidade de adicionar comentários descrevendo o conjunto de alterações. Ao contrário CVCS, a mensagem de confirmação é por commit de conjunto de alterações, em vez de por arquivo. Se você não especificá-lo na linha de comando (com a flag -m), então implementará em seu editor.

O formato padrão de uma mensagem de commit é descrito no git-commit: de forma convencional, a primeira linha contém uma descrição da mudança no tempo presente, seguida por uma linha em branco, seguida por mais mudanças descritivas, se necessário. Como de costume, o último parágrafo consiste em pares Key: values que podem ser usados para gravar informações arbitrárias, como com que problemas estão associados, quem assinou a mudança etc. Uma mensagem de confirmação pode se parecer com:

Handle legacy encodings

By default we expect UTF-8; however,
we should handle cases where it is not.

Bug: 123
Signed-off-by: Alex Blewitt <Alex.Blewitt@gmail.com>
Change-Id: Ia2dd79e7d8fd33e9940f7eb9cf68ece2cfcf9e2c 

O limite lógico de 50 caracteres para a primeira linha não é imposto, mas uma vez que alguns comandos mostram apenas a primeira (em particular, git log –oneline) então faz sentido manter esse nível. Tal como acontece com outros sistemas de controle de versão, a mensagem de commit deve explicar a intenção por trás do conjunto de alterações, e não os detalhes da implementação atrás da mudança (desde que possa ser derivado de qualquer maneira o diff).

Adicionando alterações subsequentes

Uma diferença do Git é que a alteração posterior dos arquivos também precisam de um git add. O Git tem um conceito chamado index. Quando você faz uma adição, não está apenas adicionando o arquivo ao repositório, e sim adicionando uma versão específica do arquivo ao repositório.

Para se afirmar com Git, você pode usar como padrão o git commit -a. Isso tem o mesmo efeito que a adição de todos os arquivos adicionados anteriormente, o que pode ser o que você esperava inicialmente. Executar o git status irá dizer o que é excepcional.

Configurando um repositório compartilhado

Repositórios Git compartilhados

Se você tem uma equipe trabalhando em um repositório Git, então, em algum ponto, vai querer permitir que ela possa unir suas alterações. Isso geralmente é feito com um servidor centralizado ao qual todos os desenvolvedores têm acesso (existem modelos mais flexíveis, que ignoraremos por agora).

Para configurar um repositório compartilhado, normalmente você escolhe logar via SSH. A maneira mais fácil de conseguir isso é por meio de autenticação por chave pública. Uma vez que esteja configurada (ou você decidir usar a autenticação baseada em senha), um repositório compartilhado se torna tão simples como executar:

$ ssh hostname git init --shared --bare /path/to/repo.git

Agora você será capaz de clonar isso usando:

$ git clone ssh://hostname/path/to/repo.git

Permissões

O repositório está configurado com as permissões padrões umask. Se seus desenvolvedores estão todos predefinidos para estar no mesmo grupo, então todos eles devem ter os mesmos direitos de acesso. Se não, você pode precisar alterar o grupo do repositório para limitar o acesso ao grupo apropriado de usuários:

$ ssh hostname chgrp -R devgroup /path/to/repo.git
$ ssh hostname chmod -R g+wX,o= /path/to/repo.git
$ ssh hostname find /path/to/repo.git -type d -exec chmod g+s '{}' ';'

Já que o comando chgrp anula o bit do grupo compartilhado, temos que colocá-lo de volta com o último find. Poderíamos ter feito o chmod especificando git init –bare –shared=660, mas ainda teríamos que reparar o bit do grupo caso a gente mudasse o grupo para outra coisa.

?

Textos originais disponíveis em http://alblue.bandlem.com/2011/03/git-tip-of-week-adding-content.html e http://alblue.bandlem.com/2011/03/git-tip-of-week-setting-up-shared.html