Git - Funcionamento e Workflow

Transcrição

Git – Funcionamento e
Workflow
Pesquisa e
Desenvolvimento
Tecnológico
2
Essa página foi deixada em branco intencionalmente.
Git - Funcionamento e Workflow - Git
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.
3
4
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 ...................................................................................................... 10
Trabalhando em uma Tarefa Reprovada (SEM dependência de outro Branch)................................................................. 13
Trabalhando em uma Tarefa Reprovada (COM dependência de outro Branch)................................................................ 14
Programação em Par na Mesma Tarefa ............................................................................................................................. 16
Comando Avulsos ............................................................................................................................................................................... 18
Analista .................................................................................................................................................................................................. 19
Criando Repositórios .......................................................................................................................................................... 20
Gerando Versão para o QA Tester...................................................................................................................................... 20
Aprovando Branches para o Develop ................................................................................................................................. 21
Aprovando Versão oficial e marcando com Tag ................................................................................................................. 21
Criando Branches de Hotfix para a Ultima Versão Oficial .................................................................................................. 22
Resolução de Problemas em Commits com resets errados ............................................................................................... 22
Aproveite ............................................................................................................................................................................................... 23
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
dd286
778ae
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.
5
6
41a12 (ID1533)
a44fb (Master)
dd286
778ae (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.
ID2012
a44fb (Master)
dd286
778ae
41a12 (ID1533 Develop)
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,
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
Experimentos
Botão
Alinhamento
ID2012
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 http://git-scm.com/. 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
git
git
git
config
config
config
config
--global
--global
--global
--global
user.name "Meu Nome"
user.email "[email protected]"
core.autocrlf false
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
7
8
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 fetch
git checkout -b IDxxxx origin/Develop
git gui
# Para fazer commits
####################################################################
# Fazendo Backups no origin
$ git push origin :IDxxxx
$ git push origin IDxxxx
####################################################################
# Fazendo experimentos
$ git checkout -b IDxxxxExp
# Sem alterações pendentes.
$ git gui
####################################################################
# 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 fetch
$ 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
####################################################################
#Finalizando Tarefa.
$ git fetch
# 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.
#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.
$ git 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 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.
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.
# 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 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.
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
9
10
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 fetch
# 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.
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 fetch
# Fazendo o squash.
$ git commit
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
####################################################################
# 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 checkout IDxxxxwork
$ git rebase IDxxxxbase
####################################################################
# Finalizando a tarefa.
# Crie o branch final - Nao precisa fazer o rebase dos branchs para isso.
$ git fetch
$ 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 commit
# Envie para o remote.
####################################################################
# Apagando os branches base e work locais e remotos.
$ git fetch
$ 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.
$ 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.
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.
$ git checkout -b IDxxxxwork IDxxxxbase
Nesse ponto, você pode trabalhar normalmente, como por exemplo, fazendo experimentos e outras tarefas
corriqueiras.
11
12
$ 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.
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 fetch
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
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 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 fetch
git branch -D IDxxxxbase
git branch -D IDxxxxwork
Se houver branches remotos
git push origin :IDxxxxbase
git push origin :IDxxxxwork
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 fetch
$ 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)
# 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#
####################################################################
# 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 fetch
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.
# Removendo branch local
$ git checkout -b IDxxxx origin/IDxxxx # Criando Cópia
13
14
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
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#
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.
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
####################################################################
$ 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#
####################################################################
$ git checkout -b IDxxxxwork
####################################################################
Desse ponto em diante NÃO FAÇA MAIS REBASE, somente o “—onto” para
concluir a tarefa.
####################################################################
$ git gui
####################################################################
# Faça back-up.
####################################################################
# Finalizando a tarefa.
# Crie o branch final - Nao precisa fazer o rebase dos branchs para isso.
$
$
#
#
$
#
$
$
#
$
git fetch
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
Fazendo squash.
git reset --soft fix#
git commit
Envie para o remote.
git push origin IDxxxx
####################################################################
# Apagando os branches base e work locais e remotos.
$ git fetch
$ git branch -D IDxxxxbase
$ git branch -D IDxxxxwork
# Se houver branches remotos
$ git push origin :IDxxxxbase
$ git push origin :IDxxxxwork
####################################################################
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.
####################################################################
# 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
#...
#...
# Continue a tarefa normalmente.
#
15
16
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.
# 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 merge IDxxxx
# Enviando experimento.
# Remova o branch - Esse passo deve ser feito se você vai usar o branch
# ou não.
# 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
# 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
####################################################################
#Finalizando Tarefa - Todos os usuário já deverão ter feito seus
# pushs e pulls nesse ponto.
$ git fetch
# Quando houver mais de um commit, faça squash.
$ git commit –m
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.
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
# 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!
17
18
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 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 fetch
# Quando houver mais de um commit, faça squash.
$ git commit –m
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
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
$ git fetch
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.
19
20
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 fetch
$ 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.
$
$
#
$
$
$
$
#
$
git checkout –b IDxxxx origin/IDxxxx
Não é necessário deletar o branch do remote se a tarefa é apenas local.
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 fetch
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 checkout –b IDxxxx origin/IDxxxx
git rebase Develop
git checkout Develop
git merge 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
git
git
git
git
git
fetch
checkout Develop
pull origin Develop
push origin Develop
checkout master
pull origin master
21
22
$
$
$
$
$
git
git
git
git
git
rebase Develop
merge Develop
push origin master
tag –a v5.00b –m “Versao 5.00b“
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á.
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.
o

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.
23

Git - Funcionamento e Workflow

Transcrição

Documentos relacionados

View - IFBa

Ata de reunião CAU: . Justiça em números: tudo certo nos nossos

Participação Qualificada

Participação Qualificada

DISSIPAÇÃO DA ESCURIDÃO

Edital para contratação de Professores 2016-1

Searchlight for Banking

Zend Framework 2 na prática

Relatório de Auditoria Específica

Capítulo 1 Introdução ao Controle de Versão com Git

PDF file

Conhecimentos Gerais Conhecimentos Específicos Discursiva

Regulamento Concurso Logotipo IEEELeiria SB

O básico sobre os objetos no git