Fluxo de trabalho de desenvolvimento

Você já tem sua própria cópia bifurcada do repositório Matplotlib , seguindo Fazendo sua própria cópia (bifurcação) de Matplotlib . Você configurou seu fork . Você configurou o git seguindo Configure git . Agora você está pronto para algum trabalho real.

Resumo do fluxo de trabalho

A seguir, nos referiremos à mainramificação upstream do Matplotlib, como "tronco".

• Não use seu mainramo para nada. Considere excluí-lo.

• Quando você estiver iniciando um novo conjunto de alterações, busque todas as alterações no tronco e inicie uma nova ramificação de recursos a partir dele.

• Faça uma nova ramificação para cada conjunto separável de alterações — "uma tarefa, uma ramificação" ( ipython git workflow ).

• Nomeie sua ramificação para o propósito das alterações - por exemplo, bugfix-for-issue-14ou refactor-database-code.

• Se você puder evitá-lo, evite mesclar trunk ou quaisquer outros branches em seu branch de recursos enquanto estiver trabalhando.

• Se você se encontrar mesclando do trunk, considere Rebasear no trunk

• Pergunte na lista de discussão do Matplotlib se você ficar preso.

• Solicite a revisão do código!

Essa forma de trabalhar ajuda a manter o trabalho bem organizado, com histórico legível. Isso, por sua vez, torna mais fácil para os mantenedores do projeto (pode ser você) ver o que você fez e por que o fez.

Consulte fluxo de trabalho linux git e fluxo de trabalho ipython git para obter algumas explicações.

Considere excluir sua ramificação principal

Pode parecer estranho, mas excluir seu próprio mainbranch pode ajudar a reduzir a confusão sobre em qual branch você está. Consulte excluindo main no github para obter detalhes.

Atualize o espelho do porta-malas

Primeiro, certifique-se de ter feito Vinculando seu repositório ao repositório upstream .

De vez em quando, você deve buscar as alterações upstream (tronco) do github:

git fetch upstream

Isso irá puxar para baixo todos os commits que você não possui, e definir os branches remotos para apontar para o commit correto. Por exemplo, 'trunk' é a ramificação referida por (remote/branchname) upstream/main- e se houver confirmações desde a última vez que você verificou, upstream/mainserá alterado depois que você fizer a busca.

Crie uma nova ramificação de recursos

Quando estiver pronto para fazer algumas alterações no código, você deve iniciar uma nova ramificação. Ramos que são para uma coleção de edições relacionadas são geralmente chamados de 'ramos de recursos'.

Fazer uma nova ramificação para cada conjunto de alterações relacionadas tornará mais fácil para alguém revisar sua ramificação e ver o que você está fazendo.

Escolha um nome informativo para o ramo para lembrar a si mesmo e ao resto de nós para que servem as mudanças no ramo. Por exemplo add-ability-to-fly, ou bugfix-for-issue-42.

# Update the mirror of trunk
git fetch upstream
# Make new feature branch starting at current trunk
git branch my-new-feature upstream/main
git checkout my-new-feature

Geralmente, você deseja manter suas ramificações de recursos em seu fork github público do Matplotlib . Para fazer isso, git push esta nova ramificação para seu repositório github. Geralmente (se você seguiu as instruções nestas páginas, e por padrão), git terá um link para seu repositório github, chamado origin. Você envia para seu próprio repositório no github com:

git push origin my-new-feature

Em git >= 1.7 você pode garantir que o link esteja configurado corretamente usando a --set-upstreamopção:

git push --set-upstream origin my-new-feature

A partir de agora, o git saberá que my-new-featureestá relacionado ao my-new-featurebranch no repositório do github.

O fluxo de trabalho de edição

Visão geral

# hack hack
git add my_new_file
git commit -am 'NF - some message'
git push

Mais detalhadamente

1. Faça algumas alterações

2. Veja com quais arquivos foram alterados (consulte git status ). Você verá uma listagem como esta:git status

   # On branch ny-new-feature
   # Changed but not updated:
   #   (use "git add <file>..." to update what will be committed)
   #   (use "git checkout -- <file>..." to discard changes in working directory)
   #
   #  modified:   README
   #
   # Untracked files:
   #   (use "git add <file>..." to include in what will be committed)
   #
   #  INSTALL
   no changes added to commit (use "git add" and/or "git commit -a")
   

3. Verifique quais são as alterações reais com ( git diff ).git diff

4. Adicione quaisquer novos arquivos ao controle de versão (consulte git add ).git add new_file_name

5. Para confirmar todos os arquivos modificados na cópia local do seu repositório, faça . Observe as opções para . O sinalizador apenas sinaliza que você digitará uma mensagem na linha de comando. A bandeira - você pode simplesmente acreditar - ou ver por que a bandeira -a? — e a útil descrição do caso de uso no emaranhado problema da cópia de trabalho . A página de manual git commit também pode ser útil.git commit -am 'A commit message'-amcommitma

6. Para enviar as alterações para seu repositório bifurcado no github, faça um (consulte git push ).git push

Solicite que suas alterações sejam revisadas ou mescladas

Quando estiver pronto para pedir a alguém para revisar seu código e considerar uma mesclagem:

1. Vá para a URL do seu repositório bifurcado, digamos https://github.com/your-user-name/matplotlib.

2. Use o menu suspenso 'Alternar ramificações' próximo ao canto superior esquerdo da página para selecionar a ramificação com suas alterações:

   

3. Clique no botão 'Puxar solicitação':

   

   Insira um título para o conjunto de alterações e alguma explicação do que você fez. Diga se há algo para o qual você gostaria de atenção especial - como uma alteração complicada ou algum código com o qual não está satisfeito.

   Se você acha que sua solicitação não está pronta para ser mesclada, basta dizer isso em sua mensagem de solicitação pull. Essa ainda é uma boa maneira de obter uma revisão preliminar do código.

Algumas outras coisas que você pode querer fazer

Excluir uma ramificação no github

git checkout main
# delete branch locally
git branch -D my-unwanted-branch
# delete branch on github
git push origin :my-unwanted-branch

Observe os dois pontos :antes my-unwanted-branch. Veja também: https://help.github.com/articles/pushing-to-a-remote/#deleting-a-remote-branch-or-tag

Várias pessoas compartilhando um único repositório

Se você quiser trabalhar em algumas coisas com outras pessoas, onde todos estão fazendo commit no mesmo repositório, ou até mesmo no mesmo branch, então apenas compartilhe via github.

Primeiro bifurque o Matplotlib em sua conta, a partir de Fazendo sua própria cópia (bifurcação) do Matplotlib .

Em seguida, vá para a página do github do seu repositório bifurcado, diga https://github.com/your-user-name/matplotlib

Clique no botão 'Admin' e adicione qualquer outra pessoa ao repositório como colaborador:

Agora todas essas pessoas podem fazer:

git clone https://github.com/your-user-name/matplotlib.git

Lembre-se de que os links que começam com httpsou git@são de leitura e gravação e git@usam o protocolo ssh.

Seus colaboradores podem confirmar diretamente nesse repositório com o habitual:

git commit -am 'ENH - much better code'
git push origin main # pushes directly into your repo

Explore seu repositório

Para ver uma representação gráfica dos branches e commits do repositório:

gitk --all

Para ver uma lista linear de commits para este branch:

git log

Você também pode consultar o visualizador de gráficos de rede do seu repositório github.

Finalmente, o alias de saída de log Fancy lg fornecerá um gráfico baseado em texto razoável do repositório.

Rebase no trunk

Digamos que você pensou em algum trabalho que gostaria de fazer. Você atualiza o espelho do tronco e cria uma nova ramificação de recursos chamada cool-feature. Neste estágio, o trunk está em algum commit, vamos chamá-lo de E. Agora você faz alguns novos commits em seu cool-featurebranch, vamos chamá-los de A, B, C. Talvez suas alterações demorem um pouco ou você volte a elas depois de um tempo. Nesse ínterim, o trunk progrediu do commit E para o commit (digamos) G:

      A---B---C cool-feature
     /
D---E---F---G trunk

Nesta fase, você considera a fusão do tronco em sua ramificação de recurso e lembra que esta página aqui o aconselha severamente a não fazer isso, porque o histórico ficará confuso. Na maioria das vezes você pode apenas pedir uma revisão, e não se preocupar que o porta-malas tenha se adiantado um pouco. Mas, às vezes, as mudanças no tronco podem afetar suas mudanças e você precisa harmonizá-las. Nesta situação, você pode preferir fazer um rebase.

rebase pega suas alterações (A, B, C) e as reproduz como se tivessem sido feitas no estado atual de trunk. Ou seja, neste caso, ele pega as alterações representadas por A, B, C e as reproduz em cima de G. Após o rebase, seu histórico ficará assim:

              A'--B'--C' cool-feature
             /
D---E---F---G trunk

Veja rebase sem lágrimas para mais detalhes.

Para fazer um rebase no trunk:

# Update the mirror of trunk
git fetch upstream
# go to the feature branch
git checkout cool-feature
# make a backup in case you mess up
git branch tmp cool-feature
# rebase cool-feature onto trunk
git rebase --onto upstream/main upstream/main cool-feature

Nesta situação, onde você já está no branch cool-feature, o último comando pode ser escrito de forma mais sucinta como:

git rebase upstream/main

Quando tudo parecer bom, você pode excluir sua ramificação de backup:

git branch -D tmp

Se não parecer bom, talvez seja necessário dar uma olhada em Recuperando-se de confusões .

Se você fez alterações em arquivos que também foram alterados no trunk, isso pode gerar conflitos de mesclagem que você precisa resolver - consulte a página man git rebase para obter algumas instruções no final da seção "Descrição". Há alguma ajuda relacionada à mesclagem no manual do usuário git - consulte resolvendo uma mesclagem .

Recuperando-se de confusões

Às vezes, você estraga mesclagens ou rebases. Felizmente, no git é relativamente simples se recuperar desses erros.

Se você errar durante um rebase:

git rebase --abort

Se você perceber que errou após o rebase:

# reset branch back to the saved point
git reset --hard tmp

Se você esqueceu de fazer um branch de backup:

# look at the reflog of the branch
git reflog show cool-feature

8630830 [email protected]{0}: commit: BUG: io: close file handles immediately
278dd2a [email protected]{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a [email protected]{2}: commit: BUG: lib: make seek_gzip_factory not leak gzip obj
...

# reset the branch to where it was before the botched rebase
git reset --hard [email protected]{2}

Reescrevendo o histórico de commits

Observação

Faça isso apenas para suas próprias ramificações de recursos.

Há um erro de digitação embaraçoso em um commit que você fez? Ou talvez você tenha feito vários falsos começos que gostaria que a posteridade não visse.

Isso pode ser feito por meio de rebase interativo .

Suponha que o histórico de commits seja assim:

git log --oneline
eadc391 Fix some remaining bugs
a815645 Modify it so that it works
2dec1ac Fix a few bugs + disable
13d7934 First implementation
6ad92e5 * masked is now an instance of a new object, MaskedConstant
29001ed Add pre-nep for a copule of structured_array_extensions.
...

e 6ad92e5é o último commit na cool-featureramificação. Suponha que queremos fazer as seguintes alterações:

• Reescreva a mensagem de confirmação para 13d7934algo mais sensato.

• Combine os commits 2dec1ac, a815645, eadc391em um único.

Fazemos da seguinte forma:

# make a backup of the current state
git branch tmp HEAD
# interactive rebase
git rebase -i 6ad92e5

Isso abrirá um editor com o seguinte texto:

pick 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
pick a815645 Modify it so that it works
pick eadc391 Fix some remaining bugs

# Rebase 6ad92e5..eadc391 onto 6ad92e5
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Para alcançar o que queremos, faremos as seguintes alterações:

r 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
f a815645 Modify it so that it works
f eadc391 Fix some remaining bugs

Isso significa que (i) queremos editar a mensagem de commit para 13d7934, e (ii) recolher os últimos três commits em um. Agora salvamos e fechamos o editor.

O Git imediatamente abrirá um editor para editar a mensagem do commit. Depois de revisá-lo, obtemos a saída:

[detached HEAD 721fc64] FOO: First implementation
 2 files changed, 199 insertions(+), 66 deletions(-)
[detached HEAD 0f22701] Fix a few bugs + disable
 1 files changed, 79 insertions(+), 61 deletions(-)
Successfully rebased and updated refs/heads/my-feature-branch.

e a história agora se parece com isso:

0f22701 Fix a few bugs + disable
721fc64 ENH: Sophisticated feature
6ad92e5 * masked is now an instance of a new object, MaskedConstant

Se deu errado, a recuperação é novamente possível, conforme explicado acima .