Ignorando a saída da compilação

É muito comum que haja um diretório temporário que não deve ser colocado sob controle de versão para aplicações compiladas.

Em primeiro lugar, a saída deve ser repetida pela reconstrução e, em segundo, Git (como outros CVSs) não comprimir dados não-textuais, assim como textuais (código-fonte do programa), uma vez que mesmo uma pequena mudança na fonte pode resultar em uma grande perturbação do binário. Além disso, ao contrário de CVCs, você não pode ter um check-out parcial de um DVCS, e assim você derrubará não só o atual, mas toda a história anterior.

Para ocultar o diretório de compilação do controle de versão, você pode usar o arquivo .gitignore. Isso pode ser posicionado em qualquer nível no repositório, e chegar a qualquer nível abaixo com curingas. Por exemplo, se tiver um processo de compilação multi-maven, você poderá fazer:

# Este é um comentário
# Ignorar alvo no nível superior
/ target /
# Ignorar targets dos projetos filhos também
/ * target / /
# E os netos ...
/ * / * / target /
# Ou você pode fazer:
target /
# Que corresponde a 'target' em qualquer pasta sub

Você também pode apenas copiar o mesmo arquivo .gitignore em todos os módulos de destino, ou mesmo fazer referência a eles com um link simbólico para o mesmo arquivo. (Nos bastidores, um arquivo com exatamente o mesmo conteúdo será hash para o mesmo valor para que a economia de espaço seja a mesma de qualquer maneira, mas pode ser mais conveniente fazer links simbólicos a um único arquivo para que as alterações feitas em qualquer lugar sejam visíveis em todas as pastas.)

A pasta de compilação depende de qual sistema você está usando; sob Xcode, é normalmente build, enquanto em outros projetos Java pode ser bin.

Você também pode usar o arquivo de ignorar para combinar com qualquer outro arquivo, como os temporários (* ~) ou o turdlets OSX (.DS_Store e ._ *).

Recuperando-se de um erro

É bem possível que, com o tempo, você perceba que adicionou a entrada ignorada, você já tem alguns arquivos no repositório comitado.

Se você acabou de comitar, a melhor coisa a fazer é remover os arquivos e alterar o commit anterior.

$ git rm build
$ git commit --amend

Isso irá reescrever a ponta da história para remover a compilação, e você poderá fazer de conta que nada aconteceu. Mas e se for uma versão mais antiga ou uma que veio de um desenvolvedor diferente?

Atenção: o que se segue irá mudar a história. Isso inclui a alteração hashes que afetarão pushing/pulling no futuro. Ele só deve ser feito com uma compreensão de que isso poderá tornar as coisas difíceis posteriormente; há um trade-off entre a fixação do repositório e deixá-lo como está. No entanto, se o código comitado construído contiver informações sensíveis (como senhas ou outros tokens de segurança), então talvez seja necessário fazer de qualquer maneira. Lembre-se, a história é escrita pelos vencedores!

Você pode corrigir uma árvore com git filter-branch. Ele executa um comando em cada commit em um ramo e, se bem sucedido, Iterando até o fim. No caso onde há uma pasta geral, como target, pode ser fácil de resolver, mas pode haver também casos mais difíceis, que são feitos em uma base de conteúdo do arquivo. Nesse caso, estou supondo que comitamos o diretório target. Precisamos de um intervalo de versão para operar; o ponto bom de onde partimos e o ponto onde estamos agora. Estou supondo que eles são badc0de e HEAD.

$ git filter-branch --tree-filter "rm -rf build" badc0de...HEAD

Isso garante que todos os commites entre badc0de e HEAD (que é a versão atual do ramo) tenham rm-rf build executado e, em seguida, recomitados. Para committs que não foram alterados, você vai acabar com o mesmo hash (e assim isso não será um problema), mas para commits cujos conteúdos foram alterados, você vai acabar com um novo valor de hash. Na sequência, commits terão um novo valor de hash, se seus conteúdos mudam ou não, uma vez que a confirmação depende tanto do conteúdo quanto do ponteiro dos pais.

Outras abordagens

O arquivo .gitignore é compartilhado com outros usuários via push/pull, e faz sentido para configurações gerais compartilhadas. No entanto, há uma entrada por repositório que você pode definir em .git/info/exclude, que se aplica a todos os arquivos em toda a árvore. Por exemplo, eu poderia ter alblue no meu arquivo .git/info/exclude, o que me permitiria tentar scripts de teste locais em um local que eu sei que não seria committed (ou identificado para o resto do mundo).

A escolha de onde colocar o .gitignore é um tanto arbitrária; você pode ter um na raiz do repositório ou um por sub-projeto (ou em locais mais profundos da árvore). Se a sua compilação é estruturada de uma forma que permite que um ou alguns locais de compilação sejam definidos no nível superior em seguida, por todos os meios só há um único .gitignore no nível superior. No entanto, muitas vezes é mais fácil entender por que pastas/arquivos não estão sendo adicionados ao olhar no .gitignore no diretório atual; então, a não ser que você tenha uma razão para fazê-lo, tente evitar referências a diretório múltiplos nos arquivos de ignorar.

?

Texto original disponível em http://alblue.bandlem.com/2011/03/git-tip-of-week-ignoring-build-output.html