Não sei em qual linguagem de programação você está escrevendo, mas tenho certeza de que você usa o Geet durante o desenvolvimento. Existem mais e mais ferramentas para dar suporte ao desenvolvimento, mas mesmo no menor projeto de teste, eu sempre começo com o comando git init . E durante o dia útil digito uma média de outras 80 equipes, referindo-me a este sistema de controle de versão.
Passei muitos nervos quando comecei a reaprender sobre o método de impressão com dez dedos. No final, essa foi a melhor decisão para melhorar seu fluxo de trabalho pessoal. Entre as próximas otimizações mais importantes está o desenvolvimento avançado do Geeta.
Muitos artigos sobre Gita foram escritos em Habr, mas eles não vão além da documentação oficial, e os autores propõem simplificar o trabalho com muletas feitas por eles mesmos. Estou certo de que é necessário estudar o Geet em exemplos concretos de tarefas e aumentar a eficiência de trabalhar com ele usando meios padronizados.
Quem se beneficiará com este artigo?
Você já dominou o conjunto de cavalheiros de Gita e está pronto para seguir em frente? Existem 2 maneiras:
- Comandos abreviados principais - aliases. Eles são quase sempre mnemônicos e fáceis de lembrar. Esquecer os comandos originais é problemático, digito-os facilmente quando necessário. Além disso, não estou confuso verificando algo no Gita enquanto escrevia o código.
- Aprenda sobre sinalizadores adicionais para as equipes, bem como sua integração entre si. Eu entendo que alguém odeia cortar. Para você também, há material interessante no artigo - como aumentar a utilidade e a conveniência da saída do comando, bem como resolver não os problemas mais triviais, mas frequentemente encontrados na prática .
Hoje, dedique algumas horas às experiências descritas no artigo e economize em cálculos aproximados seis meses de vida útil.
Bem-vindo ao gato!
Preparação
Entre os desenvolvedores, o padrão da alternativa Bash é o Zsh , um shell de software avançado que suporta ajustes finos. E entre os usuários do Zsh , o padrão é usar o Oh My Zsh , um conjunto de configurações predefinidas para o Zsh . Assim, após a instalação deste kit, tiraremos da caixa um conjunto de hacks que a comunidade vem coletando e desenvolvendo para nós ao longo dos anos.
É muito importante notar que o Zsh é para Linux , e para Mac , e até mesmo para Windows .
Instale o Zsh e o Oh My Zsh
Instale o Zsh e o Oh My Zsh acordo com as instruções com um comando:
Como a tarefa é otimizar a interação com o Geet , adicionaremos alguns plug-ins ao Zsh . Abra o ~/.zshrc e adicione plugins à lista:
plugins=(git gitfast)
Total:
git - um conjunto de aliases e funções auxiliares;gitfast - conclusão automática aprimorada para o Gita.
Configuração tig
E o toque final é a instalação do utilitário do console tig :
Falaremos mais sobre isso.
Git na prática
Lidar com Geeta é melhor resolvido com problemas específicos. Em seguida, consideramos tarefas da prática diária e opções para sua solução conveniente. Para fazer isso, considere um determinado repositório com arquivos de texto.
Os blocos amarelos indicam o alias principal para resolver o problema da seção. Aprenda apenas isso e deixe todo o resto para o desenvolvimento geral.
Verifique o status do diretório de trabalho
Vamos começar com a coisa mais básica. Nós fizemos um pouco de trabalho e agora vamos ver o que acontece no diretório de trabalho:
$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: e.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: b.md Untracked files: (use "git add <file>..." to include in what will be committed) d.md
O status atual de todos os arquivos é descrito em grande detalhe, são fornecidas instruções adicionais para ação. É muito útil no início ao usar o Geeta, mas há muito excesso de trabalho diário. Vamos diminuir o nível de ruído com teclas adicionais:
$ git status -sb
Sim, estamos no ramo master , alteramos o b.md ( M-odified ) e criamos dois arquivos, adicionando o primeiro ao índice Geeta ( A-dded ) e deixando o segundo fora do índice ( ?? ). Curto e claro.
Resta otimizar a entrada sem fim desse comando com o pseudônimo " g it satus with b ranch" :
Mostrar status reduzido do diretório de trabalho
$ gsb
Crie uma confirmação
Nós continuamos.
Claro, você pode fazer confirmações. Mas vamos tentar otimizar a solução desta tarefa simples. Adicione todas as alterações ao índice com o alias " g it a dd a ll" :
$ gaa
Verificamos se o índice obteve exatamente o que precisamos, usando o alias " g it d iff ca ched" :
$ gdca # git diff --cached diff --git a/b.md b/b.md index 698d533..cf20072 100644 --- a/b.md +++ b/b.md @@ -1,3 +1,3 @@ # Beta -Next step. +Next step really hard. diff --git a/d.md b/d.md new file mode 100644 index 0000000..9e3752e --- /dev/null +++ b/d.md @@ -0,0 +1,3 @@ +# Delta + +Body of article.
Hummm, as alterações que resolvem uma única tarefa devem se enquadrar em uma confirmação. Aqui, as alterações nos dois arquivos não estão relacionadas de maneira alguma. Vamos d.md excluir o arquivo d.md do índice com o pseudônimo " g it re eset u ndo" :
$ gru d.md # git reset
E crie um commit com o alias " g it c ommit" :
$ gc
Escrevemos o nome do commit e salvamos. E então criamos outra confirmação para o arquivo d.md comando mais familiar usando o alias " g it c ommit me e s sa g e" :
$ gaa
E nós podemos ...
... confirme arquivos modificados do índice com um comando:
$ gcam "Add changes"
... veja alterações por palavras em vez de linhas (muito útil ao trabalhar com texto):
$ gdw
... adicione arquivos em partes (muito útil quando você precisar adicionar ao commit apenas parte das alterações do arquivo):
$ gapa
... adicione ao índice apenas arquivos já sob a supervisão do Geeta:
$ gau
Total:
Adicionar ao índice / criar confirmação
$ ga
Corrigir confirmação
O nome do último commit não explica as alterações que fizemos. Vamos reformular:
$ gc!
E no editor de texto que abrir, chamaremos mais claramente: "Add Delta article" . Tenho certeza de que você nunca usa a opção -v , embora ao editar a descrição da confirmação, ela mostre todas as alterações feitas, o que ajuda a navegar melhor.
E nós podemos ...
... faça alterações no arquivo, mas não toque na descrição:
$ gcn!
... faça todas as alterações de arquivo imediatamente no commit, sem primeiro adicionar ao índice:
$ gca!
... combine os dois comandos anteriores:
$ gcan!
Bem, é importante notar mais uma vez que, em vez de digitar o git commit -v --amend completo, usado regularmente, escrevemos apenas três caracteres:
Alterar última confirmação
$ gc!
Introdução a um novo recurso
Crie uma nova ramificação a partir do alias atual " g it c heckout b ranch" :
$ gcb erlang
Embora não, é melhor escrever um artigo sobre uma linguagem mais moderna do Elixir, também conhecido como "rancho com a chave" (a renomeação no Gita é feita por meio de move ):
$ gb -m elixir
Seria lógico usar o apelido gbmv , mas, infelizmente, ele ainda não foi inventado. Uma boa opção para uma contribuição.
Fazemos alterações no repositório e criamos uma confirmação, como já sabemos:
$ echo "# — ." > e.md $ gaa && gcmsg "Add article about Elixir"
E lembre-se:
Crie uma nova ramificação
$ gcb
Mesclar alterações
Agora adicionamos nosso novo artigo sobre o Elixir para master . Primeiro, mude para o ramo principal com o pseudônimo " g it heckout m aster" :
$ gcm
Na verdade Um dos comandos mais usados em três caracteres fáceis de lembrar. Agora, a fusão da mudança de alias é " m itgege" :
$ gm elixir
Ops, mas alguém já conseguiu fazer alterações no master . E em vez da bela história linear que foi adotada em nosso projeto, criei odiado mesclar confirmação.
Mesclar ramificações
$ gm
Excluir a última confirmação
Nada para se preocupar! Você só precisa excluir a última confirmação e tentar mesclar as alterações novamente “ g it reset hh ard” :
Excluir última confirmação
$ grhh HEAD~
Resolvemos conflitos
A sequência padrão de checkout – rebase – merge para preparar um histórico de alterações linear é realizada pela seguinte sequência de aliases:
gco elixir
Todos eles são usados com tanta frequência que já estão voando longe dos dedos e, ao realizar essas operações, não há necessidade de pensar em qual conjunto de letras digitar. E não esqueça que no Zsh você pode complementar os nomes dos ramos com a tecla Tab .
Faça um rebase
$ grb
Enviando Mudanças para o Servidor
Primeiro, adicionamos origin alias " g it r emote a dd" :
$ gra origin git@github.com/...
E então enviamos as alterações diretamente para a ramificação atual do repositório ( “gg” - g duplicado no início do comando indica a execução da ação na ramificação atual):
$ ggpush
Você também pode ...
... envie as alterações para o servidor com a instalação upstream do alias " g it p ush s et up stream" :
$ gpsup
Enviar alterações para o servidor
$ gp
Recebemos alterações do servidor
O trabalho está em pleno andamento. Conseguimos adicionar um novo artigo f.md ao master e nossos colegas alteraram o artigo a.md e enviaram essa alteração para o servidor. Essa situação também é resolvida de maneira muito simples:
$ gup
Em seguida, você pode enviar alterações com segurança para o servidor. O conflito está resolvido.
Obter alterações do servidor
$ gl
Excluir ramificações mescladas
Portanto, mesclamos com êxito várias ramificações no master , incluindo a ramificação elixir do exemplo anterior. Não precisamos mais deles. Você pode remover o alias " g it b ranch dete a nother" :
$ gbda
Equipe muito bonita e astuta. Geralmente esqueço de limpar galhos que perderam relevância e essa equipe graciosa é uma verdadeira salvação. Se você não quiser usar um alias, basta copiar a versão completa do comando em suas anotações e executá-lo conforme necessário.
Crie uma confirmação temporária
O trabalho em um novo artigo do h.md sobre Haskell está a todo vapor. Meio escrito e você precisa receber feedback de um colega. Sem pensar duas vezes , digitamos o alias " g or w ink rogress" :
$ gwip
E, em seguida, um commit é criado com o nome Work in Progress , ignorando o IC e excluindo os arquivos "extras". Enviamos a filial para o servidor, conversamos sobre esse colega e aguardamos a revisão.
Em seguida, esse commit pode ser desfeito e os arquivos retornados ao seu estado original:
$ gunwip
E para verificar se há confirmações WIP em sua filial, use o comando:
$ work_in_progress
O comando gwip é um análogo bastante confiável do stash quando você precisa mudar para um ramo vizinho. Mas no Zsh existem muitos apelidos para o próprio stash .
Adicionar confirmação temporária / Redefinir confirmação temporária
$ gwip $ gunwip
Ocultando alterações
Você precisa ter cuidado com este comando. Os arquivos podem ser ocultados e excluídos completamente com uma ação descuidada, pois existe um reflog no qual você pode tentar encontrar o trabalho perdido.
Vamos ocultar os arquivos nos quais estamos trabalhando com o alias:
$ gsta
E então retorne-os de volta com o pseudônimo " g it st ash p op" :
$ gstp
Ou o método mais seguro de “aplicar todas as regras” :
$ gstaa
Você também pode ...
... veja exatamente o que escondemos:
gsts
... use abreviações para comandos relacionados:
gstc
Ocultar alterações / obter alterações
$ gsta $ gstaa
Procurando por um bug
A ferramenta git-bisect , que salvou várias vezes minha vida, também possui seus próprios aliases. Começamos iniciando o procedimento de “busca de erro binário” com o alias “ g it b i sect s tart” :
$ gbss
Observamos que o commit atual, último no ramo, contém um erro com o alias " g it b i s ect b ad" :
$ gbsb
Agora, marcamos o commit que nos garante o estado operacional do aplicativo "como ele é feito " :
$ gbsg HEAD~20
E agora resta responder às perguntas de Gita com as frases gbsb ou gbsg e, depois de encontrar o culpado, redefina o procedimento:
$ gbsr
E eu realmente escrevo essas abreviações ao usar esta ferramenta.
Erro ao confirmar a pesquisa
$ gbss
Estamos procurando o instigador da ilegalidade
Mesmo com uma alta porcentagem de cobertura de código nos testes, ninguém fica imune a uma situação em que o aplicativo trava e gentilmente aponta para uma linha específica com erro. Ou, por exemplo, no nosso caso, queremos descobrir quem cometeu um erro na segunda linha do arquivo a.md Para fazer isso, execute o comando:
$ gbl a.md -L 2
Veja bem, os contribuidores do Oh My Zsh criaram um pseudônimo não apenas para a equipe de git blame do git blame , mas adicionaram chaves para facilitar a localização direta do instigador.
Bônus
Exibir uma lista de confirmações
Para visualizar a lista de confirmações, use o comando git log com chaves de formatação de saída adicionais. Normalmente, este comando, juntamente com as teclas, é inserido nos aliases personalizados do Gita. Temos mais sorte, já temos um pseudônimo pronto para glog : glog . E se você instalou o utilitário tig seguindo as orientações do início do artigo, você é um campeão absoluto.
Agora, para aprender o histórico de confirmações no console de uma maneira muito conveniente, você precisa digitar a palavra git vice-versa:
$ tig
O utilitário também fornece algumas adições úteis que não estão no Gita prontas para uso.
Primeiro, um comando para pesquisar o conteúdo de uma história:
$ tig grep
Em segundo lugar, visualizando uma lista de todas as fontes, filiais, tags e seu histórico:
$ tig refs
Em terceiro lugar, talvez você encontre algo interessante para si mesmo:
$ tig --help
git reset --hard acidental do git reset --hard
Você trabalhou no ramo do elixir o dia todo:
$ glog * 17cb385 (HEAD -> elixir) Refine Elixir article * c14b4dc Add article about Elixir * db84d54 (master) Initial commit
E no final, eles apagaram acidentalmente tudo:
$ grhh HEAD~2 HEAD is now at db84d54 Initial commit
Não há necessidade de entrar em pânico. A regra mais importante é parar de executar qualquer comando no Gita e expirar . Todas as ações com o repositório local são registradas em um log - reflog especial. A partir dele, você pode obter o hash da confirmação desejada e restaurá-lo na árvore de trabalho.
Vejamos o reflog, mas não da maneira usual pelo git reflog , mas mais interessante com uma transcrição detalhada:
$ glg -g
Localize o hash do commit 17cb385 desejado e restaure-o:
Por acaso, em vez de criar um novo commit, fiz alterações no anterior
Aqui, novamente, chegamos à ajuda de resgate reflog. Encontramos o hash do commit 17cb385 original. Se cancelarmos o commit imediatamente, em vez de procurar o hash, podemos usar o link rápido para HEAD@{1} . Em seguida, fazemos uma redefinição suave, enquanto o índice não é redefinido:
O ramo é muito antigo
Às vezes, você começa a trabalhar em um recurso, mas seu lançamento é adiado indefinidamente. Você confirma e muda para outras tarefas. Juntamente com a equipe, você faz várias alterações no mestre e depois de um tempo retorna ao ramo com recursos. Você tenta se recuperar, mas ele oferece a análise de conflitos em uma dúzia de confirmações. Você pode tentar resolvê-los todos ou facilitar.
Vejamos um exemplo de um ramo de recurso chamado elixir :
Portanto, em vez de tentar atualizar o ramo, pegamos e transferimos um único commit sem problemas.
Removendo dados importantes do repositório
Para excluir dados importantes do repositório, salvei o seguinte snippet:
$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <path-to-your-file>' --prune-empty --tag-name-filter cat -- --all && git push origin --force --all
A execução deste comando quebrará seu stash . Antes de sua execução, é recomendável obter todas as alterações ocultas. Leia mais sobre esta técnica aqui .
Referindo-se à ramificação anterior
Ao executar alguns comandos que esperam que um nome de filial seja digitado, podemos passar um hífen como referência à filial com a qual viemos. É especialmente bom usar este truque de pagamento:
$ gco -
Exclua todos os arquivos marcados em .gitignore
Outro revés comum é tarde demais para adicionar arquivos ou diretórios indesejados ao .gitignore . Para limpá-los do repositório ( e excluí-los do disco ), já existem chaves prontas para o comando git clean :
$ gclean -X
Cuidado!
Leia para a maneira correta.
Por que muitas equipes precisam da opção --dry-run ?
A opção --dry-run necessária apenas como precaução ao desinstalar e atualizar. Por exemplo, a seção anterior descreveu como excluir tudo o que está especificado no arquivo .gitignore . É melhor ter cuidado e usar a opção --dry-run , --dry-run lista de todos os arquivos a serem excluídos e só então execute o comando sem a opção --dry-run .
Conclusão
O artigo mostra um ponto para otimizar o trabalho do programador. Lembre-se de 10-20 abreviações mnemônicas não é difícil, esqueça a equipe original é quase impossível. Os aliases são padronizados, portanto, quando você muda a equipe inteira para o Zsh + Oh My Zsh , pode trabalhar na mesma velocidade e conforto, mesmo com a programação de pares.
Para onde ir a seguir?
Eu ofereço as seguintes opções:
- Finalmente, descubra como o Geet está organizado dentro . Isso ajuda a entender o que você está fazendo e por que o que você quer fazer não funciona.
- Não tenha preguiça de olhar novamente a documentação para os comandos:
git --help ou ghh . - Veja a lista completa de aliases no link . Tentar lembrar de todos eles é uma loucura, mas usar a lista como uma coleção de comandos e chaves interessantes para eles é uma boa idéia.
Alguns aliases são feitos de maneira não trivial, mas provam ser muito úteis na prática. Muitos dos aliases apresentados não são apenas abreviações, mas pequenas funções que otimizam ainda mais o trabalho. O uso do Git se tornou mais agradável, a qualidade das confirmações melhorou.
Espero que o material tenha sido útil e que você possa aprender algo novo por si mesmo. Ou talvez eles já tenham começado a introduzir ativamente uma nova abordagem. Boa sorte