Git Funcionamento e Workflow. Pesquisa e Desenvolvimento Tecnológico

Transcrição

1 Git Funcionamento e Workflow Pesquisa e Desenvolvimento Tecnológico

2 2 Git - Funcionamento e Workflow Essa página foi deixada em branco intencionalmente.

3 Git - Funcionamento e Workflow - Git 3 PUBLICADO POR Atual Sistemas Departamento de Desenvolvimento A informação contida neste documento representa a visão então sustentada pela Atual Sistemas sobre os assuntos abordados na data de publicação do mesmo. Uma vez que a Atual Sistemas reagirá à mudanças nas condições do mercado, este documento não deve ser interpretado como sob compromisso por parte da Atual Sistemas, e a Atual Sistemas não garante exatidão de qualquer informação apresentada após a data dessa publicação. As informações aqui contidas são apenas para propósito informativo. A Atual Sistemas NÃO FORNECE NENHUMA GARANTIA OU RESPONSABILIDADE QUANTO A INFORMAÇÃO NESSE DOCUMENTO. Esse documento é uma obra intelectual de uso restrito ao departamento de desenvolvimento da Atual Sistemas não podendo ser reproduzido, armazenado, alterado, distribuído em quaisquer que sejam os meios (eletrônico, mecânico, fotocopiado, gravado ou qualquer que seja), quer completo, quer parcial, para qualquer propósito, sem uma expressa autorização escrita da Atual Sistemas. A violação desse acordo por posse ou uso não autorizado em quaisquer das situações citadas acima representa um ato direto contra os direitos de cópia e direitos de intelectualidade e será respondida conforme o rigor da lei. 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

4 4 Git - Funcionamento e Workflow Conteúdos PUBLICADO POR... 3 GIT USO PRÁTICO... 5 Workflow padrão da Atual... 5 Instalando o git... 7 Clonando repositórios do servidor... 7 Guia de Estilo de Mensagem de Commit... 8 Desenvolvedores... 8 Cumprindo Tarefas... 8 Usando Branches que Dependem de outros Branches Trabalhando em uma Tarefa Reprovada (SEM dependência de outro Branch) Trabalhando em uma Tarefa Reprovada (COM dependência de outro Branch) Programação em Par na Mesma Tarefa Comando Avulsos Analista Criando Repositórios Gerando Versão para o QA Tester Aprovando Branches para o Develop Aprovando Versão oficial e marcando com Tag Criando Branches de Hotfix para a Ultima Versão Oficial Resolução de Problemas em Commits com resets errados Aproveite... 23

5 Git - Funcionamento e Workflow - Git 5 Git Uso Prático A Atual Sistemas utiliza como sistema para gerenciamento de versão de conteúdo o aplicativo Git. Esse aplicativo não se trata de uma ferramenta de backup, mas deve ser usado no ambiente de desenvolvimento como um apoio para melhor organização e segurança ao lidar com alterações em arquivos. Assim, é de interesse de todos os membros da equipe de desenvolvimento tenham um bom entendimento do que o git se trata e como ele pode auxiliá-lo a resolver problemas comuns como: Fazer experimentos no fonte. Verificar o histórico de mudança de algum arquivo. Enviar tarefas concluídas. Detectar bugs. Workflow padrão da Atual O git favorece vários tipos de workflow para lidar com o código fonte. Nós, no entanto, temos escolhido por um tipo de workflow que favorece as condições e prioridades de nossa equipe de trabalho. No git, o repositório é feito de um composto de modificações ao conteúdo do repositório. Essas alterações são representadas pelos commits feito pelos usuários do repositório. A medida que novas alterações vão sendo acrescidas ao repositório, novo conteúdo é gerado no repositório. Assim, dependendo da alteração que você se concentrar, um diferente tipo de conteúdo você pode ter. No git as alterações geralmente possuem uma outra alterações de origem. Porém, embora uma alteração geralmente só possua uma alteração de origem, ela pode servir de origem para um número indeterminado de outras alterações. 41a12 a44fb dd ae cd2b5 5a786 Como pode ser visto no fluxo acima, o commit 778ae está sendo usado como origem para três alterações diferentes que não consegue manter relação entre si. Se eu selecionar o conteúdo da alteração 41a12, eu vou enxergar o resultado dessa alteração somada com todas as outras alterações ancestrais a esta, o que significa que as outras duas alterações paralelas a ela não estarão presente. No entanto, se eu selecione o conteúdo do commit dd286, eu só enxergaria o conteúdo, desse commit para traz, o que significa que os commits a frente seriam ignorados como se nunca tivessem existido no meu contéudo. Como pode notar, a habilidade de navegar de uma alteração para outra é algo muito poderoso que lhe permite enxergar estados diferentes que o conteúdo estava em determinado ponto. No entanto, navegar por alterações usando números de commits seria um pouco confuso. Para reselver esse problema de praticidade, o git trabalha com branches, que são como marcações que nós colocamos em um determinado commit para poder fazer alterações em um repositório a partir de um commit. 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

6 6 Git - Funcionamento e Workflow 41a12 (ID1533) a44fb (Master) dd ae (Develop) cd2b5 (ID2012) 5a786 (ID2225) Como pode ser visto de maneira mais clara, o acesso a determinados pontos do fonte se tornou mais claro com a criação de branches para marcar determinados commits. Por exemplo, as três tarefas no final do fluxo estão claramente saindo do commit marcado pelo branch Develop. Também, fica claro que o master, está dois commits atrás do develop. A vantagem de se trabalhar com branches, é que eles são como apelidos para os commits, mas eles também avançam a medida que novos commits são inseridos a frente de nossos commits. Assim A arvores anterior, poderia acabar ficando da seguinte maneira. a44fb (Master) dd ae 41a12 (ID Develop) ID2012 ID2225 Como se pode ver, com simples modificações nós podemos atualiza um branch, nesse caso o Develop, para um novo ponto, e ao mesmo tempo podemos reajustar com facilidade os dois outros commits que ainda não estão no Develop para uma nova origem, a fim de manter os ancestrais desses commits atualizados. Esse recursos nos permite montar uma infinidade de possibilidades de fluxo de trabalho para organização de contúdo. Assim, nós padronizamos um modelo bem simples: O branch master sempre aponta para o ultimo commit que represente a ultima versão liberada para o consumidor final. O Develop se origina do master e acrescenta commits analisados e aprovados pelo analista e o QA tester para a base de código, entando sempre apontado para o ultimo commit aprovado. Os branches da tarefa são branches criados pelo desenvolvedor baseado no Develop que possuem os commits que o desenvolvedor faz a medida que ele cumpre a tarefa dele e altera a base de código. Branches experimentais são branches criados pelos desenvolvedores baseados em commits de sua própria tarefa com o propósito de realizar alterações em caráter experimental que podem ou não integrar a base de código da tarefa. O branch QA é gerado pelo analista de tempos em tempo a partir do Develop com uma junção dos branches de tarefas que ele deseja que o QA Tester verifique. Os branches HD são branches criados em caráter emergencial que geralmente se originarão da ultima versão distribuída ao cliente, que se encontra no master. Esses branches são criados para se fazer pequenas alterações no código oficial para correção de bugs emergiais. Assim, a parte mais crítica e de maior interesse nesse workflow é a forma que programadores que cumprem tarefas terão que intergir com o repositório por meio da criação e envio de alterações por meio do uso de branches. Assim,

7 Git - Funcionamento e Workflow - Git 7 nós podemos ilustrar a relação entre as alterações feitas pelos programadores e as alterações relevantes no repositório da seguinte forma: Develop v5.00b IDxxxx ID1533 ID2012 Experimentos Botão Alinhamento Nova Cor Sem os dois ultimo commits O Develop em grande parte dos casos servirá como base para as demais alterações a serem geradas e ele será mantido atualizado pelo analista a medida que novas alterações forem testadas e aprovadas. Instalando o git O download do git pode ser feito a partir do endereço A versão do Windows do git instalará junto um console para podermos usá-lo de maneira mais prática. O console de uso do git é um console Unix, mesmo no Windows. Isso significa que algumas tarefas são levemente diferentes do que já estamos acostumados. Por exemplo, para acessar as unidades de disco como o C:, é preciso escrever cd /c/. Portanto, para entrar na pasta c:\vdf7\integra\, é necessário que nós digitemos cd /c/vdf7/integra. Ao executar o git pela primeira vez, faça algumas configuração necessárias. $ git config --global user.name "Meu Nome" $ git config --global user. "meu @atualsistemas.net" $ git config --global core.autocrlf false $ git config --global core.filemode false Clonando repositórios do servidor No git, o gerenciamento do conteúdo é feito de modo descentralizado. Assim, para podermos usar um repositório, é necessário fazer a clonagem do repositório inteiro. Isso significa que após clonado, um repositório não tem mais um servidor. No entanto, repositórios clonados guardam uma referencia para o repositório do qual eles foram clonados. Assim, os dois repositórios podem trabalhar juntos, um sendo local e outro sendo o remoto. Por padrão, agente só usa um remote, e o nome dele sempre será origin. A fazer uma clonagem, essa relação é criada automaticamente. O seguinte comando poderia ser usado para clonar o Integra por exemplo. cd /c/vdf7/ $ git clone ssh://atual@servergit:22/opt/git/integra.git Integra 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

8 8 Git - Funcionamento e Workflow Guia de Estilo de Mensagem de Commit A primeira linha da mensagem de commit não deve ter mais de 50 caracteres, tendo uma descrição resumida de que alteração esse commit se trata. No entanto, se esse for um commit para squash, a primeira linha só pode ter a identificação da tarefa no formato IDXXXX (ex. ID2225). As demais linhas devem ser usadas para fazer anotações em geral que tenha alguma relevância. Assim, siga as seguintes instruções. Descreva que efeito a alteração terá e não como ela foi implementada. Inclua quais razões motivaram a alteração, e contraste com o comportamento anterior. Não use mais de 70 caracteres por linha. Desenvolvedores Iremos agora delinear os passos mais corriqueiros que serão seguidos pelos desenvolvedores. Cumprindo Tarefas O git deve servir ao programador como uma ferramenta utilizada não somente para gerenciamento de versões do fonte em que o programador está trabalhando, mas como uma ferramenta de auxílio que permite ao desenvolvedor fazer back-ups, experimentação, e registro de check-points. Roteiro # Criando o Branch e fazendo commits $ git checkout -b IDxxxx origin/develop $ git gui # Para fazer commits # Fazendo Backups no origin $ git push origin :IDxxxx # Fazendo experimentos $ git checkout -b IDxxxxExp # Sem alterações pendentes. $ git gui # Para fazer commits # Trazendo experimento para o branch da tarefa após os commits $ git checkout IDxxxx $ git merge IDxxxxExp # Descartando o branch experimental (quer ele seja util ou não) $ git branch -D IDxxxxExp # Criando branchs experimentais a partir de um commit específico. $ git checkout -b IDxxxxExp 24f52 # O numero do commit no final. # Verificando se há atualizações disponíveis no repositório. $ git cherry HEAD origin/develop # Será exibido um hash se # houver atulizações. # Caso haja atualizações, aplicando atualizações no branch. $ git rebase origin/develop

9 Git - Funcionamento e Workflow - Git 9 #Finalizando Tarefa. $ git cherry HEAD origin/develop $ git rebase origin/develop # Somente se hover atulizações # Fazendo o squash. $ git reset --soft origin/develop $ git commit # Remova o branch do remote se você já tinha uma cópia no remote. $ git push origin :IDxxxx #Envie para o remote. Definição Ao receber uma tarefa, prepare o seu repositório obtendo as últimas atualizações feitas no remote origin pela inteira equipe. Para isso, use o comando fetch. Uma vez atualizado, crie um branch de tarefa com o nome IDxxxx onde xxxx representa o número da tarefa em que você trabalhará. Esse branch será criado usando o branch origin/develop como branch base. $ git checkout -b IDxxxx origin/develop Com uma boa regularidade, faça commits para esse branch a fim de manter pontos de segurança no seu fonte que você possa recorrer em casos de dificuldades. Para fazer commits, use a ferramenta gráfica do git que lhe exigirá que você revise suas alterações. $ git gui # Para fazer commits Para fazer backup do seu fonte no origin, você precisa simplesmente fazer uma cópia do seu branch para o origin. Caso você tente fazer um push e algum erro aconteça, delete o branch que já existe no servidor e então faça o push. $ git push origin :IDxxxx Caso você queira fazer algum experimento com a sua tarefa, crie um outro branch a partir do branch da sua tarefa. Para isso, não tenha nenhuma alteração pendente no seu branch aguaradando commit. $ git checkout -b IDxxxxExp # Sem alterações pendentes. No branch de experimento, faça commits para suas alterações. Após fazer o seu experimento, se você realmente quiser usar esse experimento na sua tarefa, faça um merge entre o experimento e a sua tarefa. $ git checkout IDxxxx $ git merge IDxxxxExp No entanto, se você não tiver interesse no código feito no branch de experimento, então descarte o branch de experimento. $ git checkout IDxxxx $ git branch -D IDxxxxExp Do mesmo modo, caso você queira verificar o código da sua tarefa em um commit específico para testar algum erro ou algum padrão que se desenvolveu, bastar criar branchs baseados no número do commit que você deseja retroceder o fonte. A semântica é a mesma aplicada para branches experimentais, requerendo que você delete esses branchs. $ git checkout -b IDxxxxExp 24f52 # O numero do commit no final. Atenção: Não faça commits para branches que foram criados com base em um commit específico porque o merge não sairá fast-forward, o que nós não permitimos. Caso você realmente precise criar um branch experimental 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

10 10 Git - Funcionamento e Workflow baseado em um commit específico, nesse caso, antes de fazer o merge, você terá de fazer rebase nesse branch experimental usando como base o branch da tarefa. Ao se trabalhar em uma tarefa, provavelmente o branch Develop sofrerá atualizações que talvez lhe sejam úteis. Por isso, é sempre bom que você verifique se há novas atualizações. Para verificar se há novos commits no developer, use os seguintes comandos. # Verificando se há atualizações disponíveis no repositório. $ git cherry HEAD origin/develop # Será exibido um hash se houver atulizações O fetch buscará por atualizações no remote enquanto o cherry comparará o branch da tarefa com o Develop para ver se novos commits foram adicionados ao Develop. Caso tenham sido, faça um rebase como está abaixo. # Caso haja atualizações, aplicando atualizações no branch. $ git rebase origin/develop O rebase com o develop, assim como o back-up e os commits devem ser feitos corriqueiramente. De preferência pelo menos duas vezes por dia. Por fim, ao conclui a tarefa, atualize novamente seu branch com o Develop, faça um squash e salve no servidor da mesma forma que você faz o back-up. #Finalizando Tarefa. $ git cherry HEAD origin/develop $ git rebase origin/develop # Somente se hover atulizações # Fazendo o squash. $ git reset --soft origin/develop $ git commit # Remova o branch do remote se você já tinha uma cópia no remote. $ git push origin :IDxxxx #Envie para o remote. Usando Branches que Dependem de outros Branches Em alguns casos o desenvolvedor talvez precisará, quer por conveniência ou por praticidade, do conteúdo de outras tarefas que estão em branches que ainda não foram aprovados no Develop. Em casos como esse, o programador trabalhará na tarefa com leves mudanças. A principal mudança é que você criará um branch base que terá a junção dos conteúdos que você precisar. Com base nesse branch, você criará um segundo branch onde todo o trabalho da tarefa será feito. O branch base sempre sera IDxxxxbase e o branch de uso será o IDXXXXwork. Ao concluir a tarefa, um terceiro branch será criado com a convenção normal IDxxxx onde você fará um rebase diferente para eliminar a dependência da sua tarefa com outras tarefas. Aténção. Ao fazer tarefas reprovadas, talvez você não dependa desses mecanismos. Porém, se você ainda precisar das dependências, crie o branch base, faça rebase do seu branch em cima do branch base, e trabalhe normalmente como sugere nessa seção. Atenção. Caso esse requerimento esteja sendo utilizado com programação em par, tanto administrador da tarefa como os demais desenvolvedores devem usar o modelo de branch base e branch work como sugere aqui em lugar de um único branch. Também, o envio da tarefa deve seguir o modelo aqui sugerido. Roteiro # Criando branch base com o conteúdo desejado. $ git checkout -b IDxxxxbase origin/develop # Faça quantos merge você precisar para trazer suas dependências. $ git merge origin/idyyyy

11 Git - Funcionamento e Workflow - Git 11 # Criando o branch de trabalho. $ git checkout -b IDxxxxwork IDxxxxbase # Trabalhe normalmente. $ git gui # Faça back-up. $ git push --force origin IDxxxxbase $ git push --force origin IDxxxxwork # Rebase com o master. $ git checkout IDxxxxbase $ git rebase origin/develop $ git checkout IDxxxxwork $ git rebase IDxxxxbase # Finalizando a tarefa. # Crie o branch final - Nao precisa fazer o rebase dos branchs para isso. $ git checkout -b IDxxxx IDxxxxwork # Quebrando relacionamento desse id com outras tarefas. # Esse tipo de rebase só pode ser feito uma vez. $ git rebase --onto origin/develop IDxxxxbase IDxxxx # Pode acontecer conflitos. # Fazendo squash. $ git reset --soft origin/develop $ git commit # Envie para o remote. # Apagando os branches base e work locais e remotos. $ git branch -D IDxxxxbase $ git branch -D IDxxxxwork # Se houver branches remotos $ git push origin :IDxxxxbase $ git push origin :IDxxxxwork Definição Como explicado, nós usamos o modelo de branch base e branch work. O branch base funciona como um branch normal, sendo criado a partir do origin/develop. # Criando branch base com o conteúdo desejado. $ git checkout -b IDxxxxbase origin/develop No branch base, você deve fazer merge do conteúdo das tarefas que você deseja. Portanto, para cada branch que você depende, use um comando merge. # Faça quantos merge você precisar para trazer suas dependências. $ git merge origin/idyyyy Após ter feito os merges necessários, crie o branch work. Caso uma nova dependência tenha de ser inserida após a criação do branch base, basta fazer novos merges e depois fazer um rebase no branch de trabalho. # Criando o branch de trabalho. $ git checkout -b IDxxxxwork IDxxxxbase Nesse ponto, você pode trabalhar normalmente, como por exemplo, fazendo experimentos e outras tarefas corriqueiras. # Trabalhe normalmente. 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

12 12 Git - Funcionamento e Workflow $ git gui Faça backup dos dois branches. Usaremos push force para não precisar remover manualmente possíveis backups anterios. # Faça back-up. $ git push --force origin IDxxxxbase $ git push --force origin IDxxxxwork Caso haja novos commits no Develop que lhe interessam, faça o rebase do branch base e depois do branch work para alinhar o seu histórico. # Rebase com o master. $ git checkout IDxxxxbase $ git rebase origin/develop $ git checkout IDxxxxwork $ git rebase IDxxxxbase Na finalização da tarefa você criará o branch oficial que será arquivado como branch da tarefa. Nesse momento, nós rompemos a associação que há entre a nossa tarefa e as outras tarefas que nós precisávamos. Então atualize os seus metadados e crie o branch final baseado no seu branch work. # Finalizando a tarefa. # Crie o branch final - Nao precisa fazer o rebase dos branchs para isso. $ git checkout -b IDxxxx IDxxxxwork O comando rebase --onto deve ser usado para verificar a relação que há entre o seu branch oficial, o branch base e o Develop, e com base nisso, as tarefas serão desvinculadas. Porntanto, para que tudo funcione como esperado, siga a ordem sugerida abaixo para a listagem dos branches. Durante o rebase, alguns conflitos podem acontecer, principalmente as alterações presentes no seu branch depende de algum conteúdo criado em outro branch que sofreu merge no branch base. Caso ocorram conflitos, resolva os conflitos, abra o git gui e coloque o arquivo na área verde (stage), mas não faça um commit. Apenas feche o git gui e digite git rebase --continue. # Quebrando relacionamento desse id com outras tarefas. # Esse tipo de rebase só pode ser feito uma vez. $ git rebase --onto origin/develop IDxxxxbase IDxxxx # Pode acontecer conflitos. A partir desse ponto, não use mais git rebase --onto nesse branch. Ele passou a ser um branch normal. Caso você precise de fazer um novo rebase seja lá qual for a razão, use um rebase normal. Agora, fazemos o squash para transformar todos os commits em apenas um. # Fazendo squash. $ git reset --soft origin/develop $ git commit Envie o seu código para o remote. Como você acabou de criar esse branch, não é necessário que você tente o remover. # Envie para o remote. Por fim, apague os branchs do seu repositório e do remote. # Apagando os branches base e work locais e remotos. $ git branch -D IDxxxxbase $ git branch -D IDxxxxwork # Se houver branches remotos $ git push origin :IDxxxxbase $ git push origin :IDxxxxwork

13 Git - Funcionamento e Workflow - Git 13 Trabalhando em uma Tarefa Reprovada (SEM dependência de outro Branch) Trabalhar em tarefas reprovadas é praticamente idêntico ao trabalho em novas tarefas, com a única diferença que, na maior parte das vezes, você terá de dar continuidade em uma tarefa que já está em um branch existente. Nós delinearemos agora, como reagir nesse caso. Roteiro # Buscando atualizações do servidor $ git gui # Vá no Menu Remoto e use a opção Limpar de -> origin # Caso haja um branch no servidor, será impresso origin/idxxxx $ git branch --list -r grep IDxxxx # Caso exista um branch remoto $ git branch -D IDxxxx # Removendo branch local $ git checkout -b IDxxxx origin/idxxxx # Criando Cópia # Selecionando um branch já existente (Somente se não existir um remote) $ git checkout IDxxxx # Crie uma tag para indicar onde houve a reprovação. Desse ponto em diante NÃO FAÇA MAIS REBASE, nem mesmo para concluir a tarefa. $ git tag -a fix# # Coloque o número de reprovações no #. # Siga como em uma tarefa normal, exceto no caso do SQUASH # Faça o squash como se segue. $ git reset --soft fix# $ git commit # A descrição do commit sera IDxxxx FIX# $ git push origin :IDxxxx # No final de tudo, remova a tag. $ git tag --delete fix# Definição Ao trabalhar em uma tarefa reprovada, você deverá usar o branch que está no remote, ao invés do branch local. Portanto, a única diferença é que você terá de deletar o branch local e fazer uma cópia do que você havia enviado para o remote. Antes de excluir o branch local, verifique se existe mesmo uma cópia do branch no remote. # Verificando se existe o branch no servidor $ git gui # Vá no Menu Remoto e use a opção Limpar de -> origin # Caso haja um branch no servidor, será impresso origin/idxxxx $ git branch --list -r grep IDxxxx Caso exista uma cópia no remote, remova a cópia local, e faça uma nova cópia local, como demonstrado a seguir. # Removendo branch local na existência de um remoto. $ git branch -D IDxxxx # Removendo branch local $ git checkout -b IDxxxx origin/idxxxx # Criando Cópia 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

14 14 Git - Funcionamento e Workflow No entanto, caso só exista um branch local, sem nenhuma cópia remota, apenas faça um checkout para o branch. # Selecionando um branch já existente $ git checkout IDxxxx Uma vez no branch, crie uma tag indicando o ponto em que você começará a fazer alterações da reprovação. Essa tag deve ter o nome fix seguido pelo quantidade de reprovações que a tarefa já sofreu. Por exemplo, essa você já esta corrigindo a tarefa pela terceira vez, crie uma tag com o nome fix3. # Crie uma tag para indicar onde houve a reprovação. $ git tag -a fix# # Coloque o número de reprovações no #. A partir desse ponto, você pode começar fazer alterações e commits, seguindo desse ponto em diante o que foi delineado no tópico anterior Cumprindo Tarefas. A única alteração aqui, será o modo como você fará o squash, e isso vale para qualquer caso que você estiver lidando. O squash deverá ser feito como segue abaixo, e a mensagem de commit que será inserida dever ter a identificação da tarefa com a identificação da reprovação (ex. ID2225 FIX3). $ git reset --soft fix# $ git commit # A descrição do commit sera IDxxxx FIX# Porém no final de tudo, ao ter terminado a tarefa e feito push, é necessário fazer a remoção da tag. # No final de tudo, remova a tag. $ git tag --delete fix# Trabalhando em uma Tarefa Reprovada (COM dependência de outro Branch) Este processo é praticamente idêntico ao trabalho de Tarefas Comuns COM dependência de outros Branchs, com a única diferença que, na maior parte das vezes você vai se referir ao próprio Branch ao invés do origin/develop, além de ter que usar uma Tag para ajudar na hora de fazer o Reset. Nós delinearemos agora, como reagir nesse caso: Roteiro # Criando branch base com o conteúdo desejado. $ git checkout -b IDxxxxbase origin/idxxxx # Crie a Tag e depois faça quantos merge você precisar para trazer suas dependências. $ git tag -a fix# # Coloque o número de reprovações no #. $ git merge origin/idyyyy # Criando o branch de trabalho. $ git checkout -b IDxxxxwork Desse ponto em diante NÃO FAÇA MAIS REBASE, somente o onto para concluir a tarefa. # Trabalhe normalmente. $ git gui # Faça back-up. $ git push --force origin IDxxxxbase $ git push --force origin IDxxxxwork # Finalizando a tarefa. # Crie o branch final - Nao precisa fazer o rebase dos branchs para isso.

15 Git - Funcionamento e Workflow - Git 15 $ git checkout -b IDxxxx IDxxxxwork # Quebrando relacionamento desse id com outras tarefas. # Esse tipo de rebase só pode ser feito uma vez. $ git rebase --onto origin/idxxxx IDxxxxbase IDxxxx # Pode acontecer conflitos. # Fazendo squash. $ git reset --soft fix# $ git commit # Envie para o remote. # Apagando os branches base e work locais e remotos. $ git branch -D IDxxxxbase $ git branch -D IDxxxxwork # Se houver branches remotos $ git push origin :IDxxxxbase $ git push origin :IDxxxxwork # No final de tudo, remova a tag. $ git tag --delete fix# Interropendo uma tarefa de reprovação para trabalhar em outra reprovação Há casos onde o desenvolvedor precisará parar o desenvolvimento de uma reprovação para trabalhar em outra que requer mais atenção. Nesses casos, um pequeno procedimento pode ser feito. Tudo que é necessário é apagar a tag, anotar o commit que ela estava referenciando e após ter cumprindo a outra tarefa, restabelecer a tag no commit anotado. Segue um roteiro demonstrando isso. Roteiro # Salve as alterações pendentes da reprovação que você está trabalhando $ git gui # Remova a tag de fix e anote o número SHA1 que será exibido pelo comando # ao ser executado. $ git tag --delete fix# # Selecione o branch que você deseja trabalhar e siga o reteiro normal # para tarefas excluidas criando tag e todos os outros procedimentos, e # cumpra a tarefa reprovada desejada. #... #... # Ao concluir a segunda tarefa reprovada, retorne a primeira tarefa # reprovada que você estava trabalhando e crie a tag de volta onde ela # estava anteriormente, usando o número exibido na exclusão $ git tag -a fix# 14af5d8 # Coloque o número de reprovações no #. #... #... # Continue a tarefa normalmente. # 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

16 16 Git - Funcionamento e Workflow Programação em Par na Mesma Tarefa Ao se trabalhar com programação em par, o git será usado para garantir que os programadores estão trabalhado com os mesmo arquivos e de modo consistente e colaborativo. Para isso, nós iremos fazer o rebase durante o pull, o que exige que algumas considerações de segurança sejam seguidas. Por exemplo, ao fazer branches experimentais, nunca os reutilize após ter feito um merge em seu conteúdo. Programação em par exige que um dos desenvolvedores assuma controle como Administrador do Branch. O administrador do branch precisa executar algumas tarefas em mono usuário, como criar o branch e fazer rebase no branch. Em casos como esse, os outros desenvolvedores não podem ter cópias do branch no computador local. Roteiro # Administrador do branch cria o branch e o publica no remote. $ git checkout -b IDxxxx origin/develop # Criando branch # Publicando o branch. # Desenvolvedores acessam e trabalham normalmente no branch. $ git checkout -b IDxxxx origin/idxxxx # Criando branch $ git gui # Faça commits normalmente. # Ao buscar atualizações no branch, usa-se um pull rebase. $ git pull --rebase origin IDxxxx # Buscando alterações. # Envie alterações para o origin. (Sempre faça um pull antes de enviar) # Criando Branches Experimentais. $ git checkout -b IDxxxxExp # Crie o branch $ git gui # Faça commits para o branch $ git rebase IDxxxx # Atualize o seu branch experimental. # Caso você queira confirmar o experimento no branch original da tarefa $ git checkout IDxxxx $ git merge IDxxxx $ git pull --rebase origin IDxxxx # Buscando alterações. # Enviando experimento. # Remova o branch - Esse passo deve ser feito se você vai usar o branch # ou não. $ git branch -D IDxxxxExp # NUNCA deixa de excluir o branch # o MERGE! # Para atualizar o branch com rebase, é necessário que todos os colaboradors # façam push de suas alterações e apagem o branch local, com excessão do # administrador do branch $ git checkout master $ git branch -D IDxxxx # Aguarde o administrador do branch fazer o rebase $ git checkout -b IDxxxx origin/idxxxx # Adminisrtrador do branch fazendo rebase do branch em mono usuário. $ git pull --rebase origin Develop $ git rebase origin/develop $ git push origin :IDxxxx #Finalizando Tarefa - Todos os usuário já deverão ter feito seus

17 Git - Funcionamento e Workflow - Git 17 # pushs e pulls nesse ponto. $ git cherry HEAD origin/develop $ git rebase origin/develop # Somente se hover atulizações # Quando houver mais de um commit, faça squash. $ git reset --soft origin/develop $ git commit m # Remova o branch do remote se você já tinha uma cópia no remote. $ git push origin :IDxxxx #Envie para o remote. Definição Quando mais de um programador precisa trabalhar em uma tarefa, um deles terá de assumir a reponsabilidade de administrador do branch. A primeiro passo que o administrador precisa tomar, é criar o branch e disponibilizá-lo para os outros desenvolvedores por enviá-lo para o remote. Atenção: Caso esse seja um branch reprovado, ou um branch que precisa de outras dependências, siga as regras de criação de branch desses roteiros antes de fazer o push do branch para os outros desenvolvedores. Também, siga as regras que fazem sentido, como por exemplo, usar o esquema de branches base e work no caso de um branch que depende de outros. # Administrador do branch cria o branch e o publica no remote. $ git checkout -b IDxxxx origin/develop # Criando branch # Publicando o branch. Os outros desenvolvedores irão criar um branch local para eles após esse passo usando o nome dado ao branch pelo administrador do branch. # Desenvolvedores acessam e trabalham normalmente no branch. $ git checkout -b IDxxxx origin/idxxxx # Criando branch $ git gui # Faça commits normalmente. Quando se deseja baixar commits que outros desenvolvedores já fizeram e já enviaram para o remote, use um pull -- rebase. Isso servirá para baixar os commits e fazer rebase dos seus commits a fim de manter o histórico do branch linear. Faça pulls constantemente, de preferencia após cada commit e antes de cada push. # Ao buscar atualizações no branch, usa-se um pull rebase. $ git pull --rebase origin IDxxxx # Buscando alterações. Use o comando push para enviar alterações para o origin, mas não se esqueça de usar um pull antes. # Envie alterações para o origin. (Sempre faça um pull antes de enviar) Branches experimentais funcionam de modo similar quando se trabalha com programação em par. A única diferença fundamental ao trabalhar em par é que após o merge, você deve descartar os branches experimentais imediatamente. # Criando Branches Experimentais. $ git checkout -b IDxxxxExp # Crie o branch $ git gui # Faça commits para o branch $ git rebase IDxxxx # Atualize o seu branch experimental. # Caso você queira confirmar o experimento no branch original da tarefa $ git checkout IDxxxx $ git merge IDxxxx $ git pull --rebase origin IDxxxx # Buscando alterações. # Enviando experimento. # Remova o branch - Esse passo deve ser feito se você vai usar o branch # ou não. $ git branch -D IDxxxxExp # NUNCA deixa de excluir o branch # o MERGE! 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

18 18 Git - Funcionamento e Workflow Para fazer rebases que reflitam o que está no develop, é necessário que todos os programadores faça push das suas alterações, e em seguida removam o branche local da tarefa, aguardando até que o administrador do branche faça rebase no branche. # Para atualizar o branch com rebase, é necessário que todos os colaboradors # façam push de suas alterações e apagem o branch local, com excessão do # administrador do branch $ git checkout master $ git branch -D IDxxxx Após o administrador do branch indicar que o rebase já foi feito, os outros programadores podem retornar a trabalhar nos seus branches, criando novamente um branch local. # Aguarde o administrador do branch fazer o rebase $ git checkout -b IDxxxx origin/idxxxx Antes de fazer rebase, o administrador do branch tem que ter certeza que todos os outros usuários já fizeram push de suas alterações. Em seguida, ele buscará essas alterações, fará rebase, removerá o branch remoto no origin e colocará um novo lá. Como base nesse novo branch os desenvolvedores trabalharão. # Adminisrtrador do branch fazendo rebase do branch em mono usuário. $ git pull --rebase origin Develop $ git rebase origin/develop $ git push origin :IDxxxx Quando todos os desenvolvedores já tiverem feito push de seus commits, o administrador do branch pode encerrar a tarefa. Ele verificará a necessidade de fazer rebase, e fará um squash para um melhor histórico. Após isso ele deve remover o branch que está no servidor e deve subir um novo. #Finalizando Tarefa - Todos os usuário já deverão ter feito seus # pushs e pulls nesse ponto. $ git cherry HEAD origin/develop $ git rebase origin/develop # Somente se hover atulizações # Quando houver mais de um commit, faça squash. $ git reset --soft origin/develop $ git commit m # Remova o branch do remote se você já tinha uma cópia no remote. $ git push origin :IDxxxx #Envie para o remote. Comando Avulsos Nessa seção segue uma lista de comandos que podem ser usados para algumas tarefas específicas no git. Exibir divergências que há entre os seus branches e os branches do servidor. $ git log --branches --not --remotes=origin Marcar um arquivo para ser removido do seu branch no próximo commit. $ git rm NomeDoArquivo Criar uma Tag baseado no commit corrente. $ git tag a NomeTag m Mensagem Tag Revertendo um arquivo alterado ao estado que ele estava com o ultimo commit. $ git checkout MeuArquivo

19 Git - Funcionamento e Workflow - Git 19 Reverter todos os arquivos alterados para o ultimo commit. $ git checkout --. Copiando um arquivo de um commit ou branch específico para o seu branch atual. $ git checkout origin/outrobranch Codigo/MeuArquivo.inf Alterando a mensagem ou as alterações do ultimo commit. $ git add Codigo/OutrosArquivos.inf # Esse comando é para confirmar alterações. $ git commit --amend m Minha nova mensagem de commit Reverter todos os arquivos alterados para o ultimo commit. $ git checkout --. Vendo os branchs locais com o branch ativo marcado. $ git branch Vendo todos os branchs $ git branch list Copiando um commit individual para o seu histórico. $ git cherry-pick 454F45 Renomeando arquivos rastreados $ git mv Fontes/foo.vw Fontes/bar.vw Removendo arquivos rastreados $ git rm AppSrc/foobar.vw Consultando logs locais em caso de problemas $ git reflog Eliminando conflito de chaves SSL em conexões SSH $ rm fr ~/.ssh Restaurando origin quando excluído acidentalmente $ git remote add origin ssh://usuario@servidor:922/opt/git/nome_do_projeto.git Analista O trabalho do analista ao usar o git está muito relacianado ao workflow adotado pela atual para lidar com o conteúdo do repositório. O analista, semelhante aos desenvolvedores, executará as tarefas citadas para os desenvolvedores de maneira similar. Porém, há algumas tarefas que somente o analista faz. Essas são: Criar repositórios Gerar versões para o QA Tester Aprovar branches para o Develop Aprovando versão oficial e marcando com Tag Criar branches de hotfix que unificam conteúdo de uma versão oficial com branches de tarefas feitas para versões mais recentes por algum desenvolvedor. 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

20 20 Git - Funcionamento e Workflow Criando Repositórios Para criarmos um repositório é necessário se conectar ao remote que desejamos armezanar uma cópia de nosso repositório. $ ssh p 22 atual@gitserver $ cd /opt/git/ $ mkdir meurepositorio.git # Cria o diretório do repositório use.git no final. $ cd meurepositorio.git $ git init --bare --shared # Inicia o repositório no remote $ logout Após ter criado o repositório no servidor, faça um clone desse repositório vazio para o seu computador. cd /c/vdf7/ $ git clone ssh://atual@servergit:22/opt/git/meurepositorio.git MeuRepositorio Após isso, configure o arquivo.gitignore e crie ou copie o conteúdo do projeto para dentro do diretório usado no seu computador para o repositório. Caso você apenas queira criar um repositório local sem se preocupar com o uso de um remote para armazenamento, apenas use um simples git init dentro da pasta raiz do seu projeto. Gerando Versão para o QA Tester De tempos em tempos é necessário gerar uma versão que será usada pelo QA Tester. Essa versão basicamente deve corresponder ao que já foi testado e aprovado (Develop) somado as novas tarefas que se deseja testar. O branch que será usada para testes deve ser criado em um ciclo. Criar QA Inserir Tarefas Destruir QA QA Tester O primeiro passo, criar o QA, deve ser executado apenas uma vez. $ git checkout b QA origin/develop O segundo passo, inserir tarefas, deve ser feito uma vez para cada tarefa que se deseja inserir no QA. # Tarefas locais exigem apenas um simples checkout.

21 Git - Funcionamento e Workflow - Git 21 $ git checkout b IDxxxx origin/idxxxx $ git rebase origin/develop # Não é necessário deletar o branch do remote se a tarefa é apenas local. $ git push origin :IDxxxx $ git checkout QA $ git merge IDxxxx # Delete a cópia do branch local se houver uma cópia remota. $ git branch D IDxxxx O terceiro passso, requer que o analiste compile o programa e envie para o setor de QA. O ultimo passo, destruir QA, envolve simplesmente destruir o branch criado. $ git checkout master $ git branch D QA Aprovando Branches para o Develop O Develop possue os commits que foram aprovados pela a analise e pelo QA Tester. Quando ambos os passos indicam que a alteração está saudável, é necessário que o analista portanto envie essas alterações para o Develop. Atenção: Tome cuidado ao fazer rebases pois eles serão feitos a partir do develop local. O Develop remote só será atualizado quando todos os branches já tiverem feito merge. $ git gui # Vá no Menu Remoto e use a opção Limpar de -> origin $ git checkout Develop $ git pull origin Develop # -- Inicio da parte repetitiva a cada tarefa a ser aprovado $ git branch --list r grep IDxxxx # ATENÇÃO Apenas delete o branch local se o commando anterior indicar que existe um # remote. $ git branch D IDxxxx $ git checkout b IDxxxx origin/idxxxx $ git rebase Develop $ git checkout Develop $ git merge IDxxxx $ git branch D IDxxxx $ git push origin :IDxxxx # -- Fim da parte repetitiva da inclusão de tarefas no Develop $ git push origin Develop Aprovando Versão oficial e marcando com Tag Conforme já bem explicado, a versão oficial que será distribuída sempre está no master. Assim, quando o conteúdo de Develop possuem os recursos requeridos para uma nova versão, o branch master deve ser atualizado para o ponto onde Develop aponta. Assim, aprove todos os branches que você precisa aprovar para Develop primeiro. Então, comece atualizar o branch master. Uma leve diferença nesse caso é o uso de tags. Tags, de maneira similar a branches, servem para marcar determinado commit como tendo certa relevância no histórico do conteúdo do repositório. A diferença de tags para branches é que elas não devem ser usadas como branches, que mudam de posição, são atualizados para commits mais a frente no histórico e podem ser usados como ambiente para desenvolvimento. Atenção: Ao executar esse passo, se conclui que o Develop já está exatamente como você deseja a nova versão. $ git checkout Develop $ git pull origin Develop $ git push origin Develop $ git checkout master $ git pull origin master 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.

22 22 Git - Funcionamento e Workflow $ git rebase Develop $ git merge Develop $ git push origin master $ git tag a v5.00b m Versao 5.00b $ git push origin refs/tags/v5.00b Criando Branches de Hotfix para a Ultima Versão Oficial Quando se deseja criar um hotfix, geralmente você se deparará com dois casos. Você deseja usar o código da ultima versão mais algumas alterações que você pretende gerar. Você deseja usar o código da ultima versão mais algum commit que foi feito recentemente para alguma tarefa baseada no Develop. O primeiro caso é mais simples, uma vez que o conteúdo que você deseja acrescentar a versão oficial ainda não existe. Nesse caso, você apenas terá de criar um branch que se baseie na versão oficial e nesse branch você fará os commits que desejar para resolver o problema. Segue exemplo abaixo. $ git checkout b HDxxxxx v5.00a $ git gui Após ter feito todas as alterações, basta compilar o código e salvar o branch no remote. O segundo caso porém é mais interessante porque ele envolve pegar o conteúdo de uma tarefa que pode estar vários commits a frente da ultima versão oficial, em um caso como esse, tentar fazer um merge simples, como algumas vezes se faz para unificar conteúdos existentes, acabaria trazendo parte conteúdo de outros commits no histórico que você não deseja. Para resolver esse problema, você precisa fazer uma cópia do commit que você deseja usar para o hotfix. Quando se faz uma cópia do commit apenas aquele commit é copiado para o novo branch, deixando os ancestrais sem nenhuma influência sobre a copia. Assim, é como se nós tivéssemos um novo commit nesse branch. $ git checkout b HDxxxxx v5.00a $ git cherry-pick origin/idxxxx Resolução de Problemas em Commits com resets errados Em alguns casos durante a execução de reprovações, o commit final entregado pelo desenvolvedor incluía um grupo de alteraçãos que não faziam parte das mudanças realizadas pelo desenvolvedor. Muitos desses problemas eram causados devido a resets da tarefa com o Develop, visto que em reprovações a tarefa tem que ser resetada para tag. Uma outra causa comum era o uso do rebase com a reprovação, o que atualizava o branch, mas não atualizava a tag. Nesse caso, ao fazer o reset com a tag, o commit final acabava incluindo uma curva de alteração que abrangia mais conteúdo do que o alterado. Em casos onde isso acontecer há algumas possíveis soluções para o problema. De maneira resumida podemos dizer que o apropriado seria tenta resolver o problema na seguinte ordem: Investigar: É necessário tentar entender o que causou o problema em primeiro lugar. O comando git reflog pode ser usado para prover um roteiro de operações locais feitas pelo usuário do git. Tentar achar o ultimo commit válido antes do rebase ou reset. Quanto nós fazemos um rebase ou um reset, uma outra versão das alterações é criada. No entanto, a versão anterior que ainda estava válida permanece no repositório sem ser referenciado por nenhum branch. Para pequisá-la, o comando git lostfound pode ser de ajuda. Esse comando exibirá uma lista de commits que não estão mais sendo referenciados no repositório, junto com a descrição do commit. o Procure pelo ultimo commit que você fez para essa tarefa, o Faça um checkout para ele e verifique como ele está.

23 Git - Funcionamento e Workflow - Git 23 o Se esse commit estiver correto, apague o seu branch de reprovação e crie um novo branch de reprovação baseado nesse commit. o Em casos de reprovação, coloque a tag de reprovação no primeiro commit que não pertence a reprovação que você está trabalhando. o Faça o processo de rebase e reset novamente. (Em casos de reprovação é reset e rebase.) Tentar anular os arquivos indesejados. Caso seja muito difícil achar o ultimo commit válido com git lost-found, e os arquivos adicionais não estejam afetando o conteúdo dos arquivos que você trabalhou, tente reverter essas alterações indesejadas do seu commit. o Use git checkout HEAD~1 NomeDoArquivo para cada arquivo indesejado, indicando que você quer o arquivo no estado que ele estava antes desse commit ser gerado. Isso fará com que a alteração seja anulada. o Corrija manualmente alterações indesejadas que estão mescladas nos arquivos com o conteúdo da sua tarefa. o Confirme tudo com um único git commit --amend. Esse simples passos serão o suficiente para resolver a grande maioria das situações. No entanto, tenha muita atenção ao efetuar cada um desses passos. As situações podem diferir tanto, que se requer mais discernimento do analista durante tais operações. Aproveite A Atual Sistemas procura utilizar o que há de melhor tanto em ferramentas como em habilidades pessoais. Acreditamos que a colaboração mútua é extremante vital para que a criação de produtos sólidos ocorra. Entetanto, nesse respeito, o valor humano é muito mais importante que um sistema de gerenciamento de versões. Acreditamos que esse manual lhes beneficiará e lhes ajudará a ter uma melhor integração com a equipe e melhor praticidade ao lidar com tarefas diárias. Estamos abertos a sugestões. 2011Atual Sistemas. Todos os direitos Reservados. Ao fazer uso desse material você está automaticamente concordando com o termo de licença na página 3.