Introdução ao Git

Sumário

Prefácio
1. Configurando o git
.... 1.1 Arquivos de configuração
.... 1.2 Configurações padrão
.... 1.3 Aliases
2. O básico do git
.... 2.1 Criando um repositório
.... 2.2 Status do arquivo
.... 2.3 Trabalhando com o índice
.... 2.4 Trabalhando com confirmações
.... 2.5 Ver histórico
.... 2.6 Trabalhando com um repositório remoto
3. Ramificação no git
.... 3.1 Operações básicas
.... 3.2 Mesclar filiais
.... 3.3 Rerere
4. Ponteiros no git
.... 4.1 Movendo ponteiros
5. Leitura recomendada

Prefácio

Git é o sistema de controle de versão distribuído mais popular. [1] [2]

O principal objetivo do Git é salvar instantâneos de melhorar sucessivamente as condições do seu projeto (Pro git, 2019).

Este artigo é para aqueles que têm pelo menos conhecimento e habilidade básicos em trabalhar com o git e desejam expandir seus conhecimentos.

Somente aspectos técnicos do git são considerados aqui. Para uma imersão mais detalhada na filosofia do git e sua implementação interna, aconselho que você leia vários livros úteis (consulte Leitura recomendada ).

1. Configurando o git

Antes de começar a trabalhar com o git, você precisa configurá-lo por conta própria!

1.1 Arquivos de configuração

• / etc / gitconfig - Configurações gerais para todos os usuários e repositórios
• ~ / .gitconfig ou ~ / .config / git / config - Configurações específicas do usuário
• .git / config - Configurações para um repositório específico

Existe uma equipe especial

git config [<>] 

o que permitirá que você altere o comportamento padrão do git, se necessário, mas você pode editar os arquivos de configuração manualmente (acho mais rápido).

Dependendo de qual parâmetro você passa para o comando git config (--system, --global, --local), as configurações serão gravadas em um desses arquivos. Cada um desses "níveis" (sistema, global, local) redefine os valores do nível anterior!

Para ver em qual arquivo quais configurações estão instaladas, use git config --list --show-origin.

Ignorando arquivos
No git, você decide quais arquivos serão inseridos em qual commit, mas talvez você deseje que certos arquivos nunca estejam no índice e no commit, e nem apareçam na lista não rastreada. Para fazer isso, você pode criar um arquivo especial (.gitignore) em seu repositório e escrever o modelo de arquivos ignorados lá. Se você não deseja criar esse arquivo em cada repositório, pode defini-lo globalmente usando core.excludesfile (consulte Configurações úteis ). Você também pode fazer o download do arquivo .gitignore finalizado para a linguagem de programação em que está trabalhando.
Para personalizar .gitignore, use expressões regulares do bash .

1.2 Configurações padrão

Existem várias configurações de git para o servidor e o cliente, apenas as configurações básicas do cliente serão consideradas aqui.

Use

 git config name value 

onde name é o nome do parâmetro e value é o valor para definir as configurações.
Um exemplo:

 git config --global core.editor nano 

instalará o editor padrão nano.

Você pode visualizar o valor de um parâmetro existente com git config --get [name], em que name é o parâmetro cujo valor você deseja obter.

Configurações úteis:

• user.name - O nome que será usado ao criar a confirmação
• user.email - Email a ser usado ao criar a confirmação
• core.excludesfile - um arquivo cujo modelo será usado para ignorar arquivos específicos globalmente
• core.editor - O editor padrão
• commit.template - O arquivo cujo conteúdo será usado para a mensagem de confirmação padrão (consulte Trabalhando com confirmações ).
• help.autocorrect - Quando definido como 1, o git executará comandos escritos incorretamente.
• credential.helper [mode] - Define o modo de armazenamento de credenciais. [cache] - as credenciais são salvas por um determinado período, as senhas não são salvas (--timeout [segundos] o número de segundos após o qual os dados são excluídos, o padrão é 15 minutos). [armazenar] - as credenciais são armazenadas por tempo ilimitado em claro (--file [arquivo] indica o caminho para armazenar dados, por padrão ~ / .git-credentials).

1.3 Aliases

Se você não quiser imprimir todos os comandos do Git na sua totalidade, poderá configurar facilmente os aliases. Para criar um alias, use:

 git config alias.SHORT_NAME COMMAND 

onde SHORT_NAME é o nome a abreviar e COMMAND o (s) comando (s) a ser abreviado. Um exemplo:

 git config --global alias.last 'log -1 HEAD' 

depois de executar este comando, você pode visualizar informações sobre o último commit no ramo atual executando git last.

Aconselho que você use as seguintes abreviações (você também pode definir qualquer um de seus):

• st = status
• ch = checkout
• br = ramo
• mg = mesclar
• cm = confirmar
• reb = rebase
• lg = "git log --pretty = formato: '% h -% ar:% s'”

Para visualizar as configurações, use: git config --list.

2. O básico do git

Somente parâmetros obrigatórios e úteis (na minha opinião) são listados aqui, porque listar tudo é inadequado. Para fazer isso, use o comando git -help ou --help, em que command é o nome do comando da ajuda que você deseja receber.

2.1 Criando um repositório

• git init [<opções>] - Cria um repositório git e um diretório .git no diretório atual (ou no diretório especificado após --separate-git-dir <git_root>; nesse caso, o diretório .git estará em outro local);
• git clone [<opções>] [-] <repositório> [<pasta>] [-o, --origin <name>] [-b, --branch <branch>] [- único ramo] [- -no-tags] [--separate-git-dir <diretório-git>] [-c, --config <key = value>] - Clona repositórios com a origem do nome (ou o que você especificar -o <name> ), estando na ramificação para a qual HEAD aponta (ou na qual você especifica -b <branch>). Você também pode clonar apenas o ramo HEAD necessário (ou o especificado em -b <branch>) especificando - único ramo. Por padrão, todas as tags são clonadas, mas especificando --no-tags você não pode cloná-las. Após a execução do comando, o diretório .git é criado no diretório atual (ou no diretório especificado após --separate-git-dir <git_root>; nesse caso, o diretório .git estará localizado em outro lugar);

2.2 Status do arquivo

Para visualizar o status dos arquivos em seu repositório, use:

 git status [<>] 

Este comando pode mostrar: em qual filial você está atualmente e o status de todos os arquivos. Não há opções necessárias, apenas -s podem ser distinguidas das úteis, o que mostrará uma breve idéia dos estados dos arquivos.

Ciclo de vida do arquivo
Como você pode ver na figura, os arquivos podem não ser rastreados e rastreados. Os arquivos monitorados podem estar em 3 estados: Não modificado (não modificado), modificado (modificado), preparado (preparado).
Se você adicionar (usando o git add) um arquivo "Não monitorado", ele entrará no estado "Preparado".
Se você alterar o arquivo para o estado "Não alterado", ele entrará no estado "Alterado". Se você salvar o arquivo modificado (ou seja, no estado "Modificado"), ele entrará no estado "Preparado". Se você confirmar um arquivo (ou seja, no estado "Preparado"), ele entrará no estado "Não alterado".
Se as versões do arquivo no HEAD e no diretório ativo forem diferentes, o arquivo estará nos estados "Modificado"; caso contrário (se a versão no HEAD e no diretório ativo forem os mesmos "), o arquivo estará nos estados" Não alterado ".
Se a versão do arquivo no HEAD for diferente do diretório de trabalho, mas não for a versão do índice, o arquivo estará no estado "Preparado".

Este ciclo pode ser representado da seguinte maneira:
Não modificado -> Modificado -> Preparado -> Não modificado
Ou seja, você modifica o arquivo, salva no índice e efetua um commit e, em seguida, novamente.

2.3 Trabalhando com o índice

Espero que você entenda como é o ciclo de vida do repositório git. Agora vamos ver como você pode gerenciar o índice e os arquivos no seu repositório git.

Um índice é um local intermediário entre seu último commit e o próximo. Você pode adicionar ou remover arquivos do índice. Quando você confirma, ele obtém dados do índice e não da área de trabalho.

Para visualizar o índice, use o status git.

Para adicionar arquivos ao índice, use

 git add [<>] 

Opções úteis de comando git add:

• -f, --force - adiciona arquivos ignorados também
• -u, --update - atualiza arquivos rastreados

Para remover arquivos do índice, você pode usar os comandos 2 git reset e git restore.
git-restore - restaura os arquivos da árvore de trabalho.
git-reset - redefine o HEAD atual para o estado especificado.
De fato, você pode conseguir a mesma coisa com os dois comandos.

Para remover alguns arquivos do índice, use:

 git restore --staged <file> 

Dessa forma, você restaurará seu índice (ou melhor, excluirá arquivos específicos do índice), como se o git add não tivesse sido executado para eles desde a última confirmação. Com este comando, você pode restaurar o diretório de trabalho para que pareça que nenhuma alteração foi feita após a confirmação. Mas esse comando tem um comportamento um pouco estranho - se você adicionou uma nova versão do seu arquivo ao índice, não poderá alterar seu diretório de trabalho até que o índice seja diferente do HEAD. Portanto, primeiro você precisa restaurar seu índice e somente então o diretório de trabalho. Infelizmente, não é possível fazer isso com um comando, pois ao passar os dois argumentos (git restore -SW) nada acontece. E da mesma forma, quando -W for passado, nada acontecerá se o arquivo no índice e HEAD forem diferentes. Provavelmente, eles fizeram isso por proteção, para que você não alterasse acidentalmente seu diretório de trabalho. Mas neste caso, por que o argumento -W é passado por padrão? Em geral, não entendo por que isso foi feito e por que esse comando foi adicionado. Para mim, redefinir lida com essa tarefa muito melhor e também possui uma funcionalidade mais rica, pois pode mover o índice e o diretório de trabalho não apenas para o último commit, mas também para qualquer outro.

Mas os próprios desenvolvedores recomendam o uso do git restore -S para redefinir o índice. Em vez de git, reinicie o HEAD.

Usando o status do git, é possível ver quais arquivos foram alterados, mas se você também quiser saber o que exatamente mudou nos arquivos, use o comando:

 git diff [<options>] 

portanto, executando o comando sem argumentos, você pode comparar seu índice com o diretório de trabalho. Se você já adicionou arquivos ao índice, use git diff --cached para ver as diferenças entre a última confirmação (ou a que você especificou) e o diretório de trabalho. Você também pode ver as diferenças entre duas confirmações ou ramificações passando-as como argumento. Exemplo: git diff 00656c 3d5119 mostra as diferenças entre confirmação 00656c e 3d5119.

2.4 Trabalhando com confirmações

Agora que seu índice está no estado certo, é hora de confirmar suas alterações. Lembre-se de que todos os arquivos para os quais você não executou o git add após a edição não estão incluídos neste commit. De fato, haverá arquivos nele, mas apenas sua versão antiga (se houver).

Para confirmar suas alterações, use:

 git commit [<>] 

Opções úteis para o comando git commit:

• -F, --file [arquivo] - Grava uma mensagem de confirmação do arquivo especificado
• --author [author] - Substitua o autor da confirmação
• --date [data] - Alterar data de confirmação
• -m, --mesage [message] - Confirmação de mensagem
• -a, --all - Confirma todas as alterações nos arquivos
• -i, --include [files ...] - Adicione os arquivos especificados ao índice para a próxima confirmação
• -o, --only [arquivos ...] - confirma apenas os arquivos especificados
• --amend - Sobrescreve o commit anterior

Você pode definir uma mensagem de confirmação padrão usando o commit.template. Essa diretiva no arquivo de configuração é responsável pelo arquivo cujo conteúdo será usado para confirmação padrão. Exemplo: git config --global commit.template ~ / .gitmessage.txt.

Você também pode alterar, excluir, mesclar qualquer confirmação.
Como você deve ter notado, você pode substituir rapidamente o último commit pelo git commit --amend.
Para alterar o commit em sua história, use

 git rebase -i <commit> 

em que commit é o principal commit da sua cadeia a partir do qual você deseja alterar alguma coisa.

Após executar o git rebase -i no menu interativo, selecione o que deseja fazer.

• escolha <confirmar> = usar confirmação
• reword <commit> = use commit, mas altere a mensagem de commit
• edit <commit> = use commit, mas pare para corrigir
• squash <commit> = usa confirmação, mas mescla com confirmação anterior
• fixup <commit> = como "squash", mas pule a mensagem de confirmação
• exec <comando> = executa o comando (restante da linha) usando o shell
• break = stop here (continue com "git rebase --continue")
• drop <commit> = excluir confirmação
• label <label> = nomeie o HEAD atual
• reset <label> = redefine HEAD para o rótulo especificado

Para alterar a mensagem de uma confirmação específica.
Você deve alterar a seleção para editar a confirmação que deseja alterar.
Exemplo: você deseja alterar a mensagem de confirmação 750f5ae.

escolha o primeiro commit de 2748cb4
editar 750f5ae segundo commit
escolha o terceiro commit 716eb99

Após salvar o script, você retornará à linha de comando e o git informará o que fazer em seguida:

Parado em 750f5ae ... segundo commit
Você pode alterar o commit agora, com

git commit --amend

Quando estiver satisfeito com suas alterações, execute

git rebase --continuar

Como indicado acima, você deve executar o git commit --amend para alterar a mensagem de confirmação. Em seguida, execute git rebase --continue. Se você selecionou várias confirmações para alterar o nome, essas operações precisarão ser realizadas em cada confirmação.

Para excluir uma confirmação
Você deve excluir a linha com o commit.
Exemplo: você deseja excluir o commit 750f5ae
Você precisa alterar o script a partir disso:
escolha o terceiro commit de 2748cb4
escolha 750f5ae segundo commit
escolha o primeiro commit 716eb99
sobre isso:
escolha o primeiro commit de 2748cb4
escolha o terceiro commit 716eb99

Para mesclar confirmações
Você deve alterar a seleção para esmagar as confirmações que deseja mesclar.
Exemplo: você deseja combinar as confirmações 750f5ae e 716eb99.
Você precisa alterar o script a partir disso:
escolha o terceiro commit de 2748cb4
escolha 750f5ae segundo commit
escolha o primeiro commit 716eb99
Em tais
escolha o terceiro commit de 2748cb4
squash 750f5ae segundo commit
primeiro commit do squash 716eb99

Observe que no script interativo, as confirmações são mostradas em ordem inversa à do log do git. Usando squash, você combina o commit 750f5ae com 716eb99 e o commit 750f5ae com 2748cb4. Como resultado, obtendo um commit contendo alterações nos três.

2.5 Ver histórico

Usando o comando

 git log [<>] [<->] 

Você pode ver o histórico de consolidação do seu repositório. Há também várias opções para classificar e procurar um commit específico.

Opções úteis de comando git log:

• -p - Mostra a diferença para cada confirmação.
• --stat - Mostra estatísticas de arquivos modificados para cada confirmação.
• --graph - Exibe um gráfico ASCII com ramificações e histórico de mesclagem.

Você também pode classificar confirmações por tempo, quantidade etc.

• - (n) Mostra apenas o último n confirma.
• --since, --after - Mostra confirmações feitas após a data especificada.
• - até, - antes - Mostra confirmações feitas antes da data especificada.
• --author - Mostra apenas aqueles commit nos quais a entrada do autor corresponde à string especificada.
• --committer - Mostra apenas aqueles commit nos quais a entrada do commit corresponde à string especificada.
• --grep - Exibe apenas confirmações cuja mensagem contém a sequência especificada.
• -S - Mostra apenas confirmações nas quais uma alteração no código resultou na adição ou remoção da linha especificada.

Aqui estão alguns exemplos:
git log --since = 3.weeks - Mostrar confirmações nas últimas 2 semanas
git log --since = "2019-01-14" - Mostra os commits feitos em 2019-01-14
git log --since = "2 anos 1 dia atrás" - Mostra os commits feitos 2 anos e um dia atrás.

Você também pode personalizar o formato de saída de confirmação com

 git log --format:["format"] 

Opções de formatação para o git log --format.

• % H - Confirmar hash
• % h - hash de confirmação reduzido
• % T - Hash de árvore
• % t - hash de árvore reduzido
• % P - Hash pai
• % p - Hash pai abreviado
• % an - Nome do autor -% ae - Email do autor
• % ad - Data do autor (o formato da data pode ser definido com a opção --date = opção)
• % ar - Data relativa do autor
• % cn - Nome do remetente
• % ce - Email do responsável
• % cd - Data de confirmação
• % cr - data de confirmação relativa
• % s - Conteúdo

Um exemplo:

 git log --pretty=format:"%h - %ar : %s" 

mostrará uma lista de confirmações consistindo em um hash de tempo e uma mensagem de confirmação.

2.6 Trabalhando com um repositório remoto

Como o git é uma moeda forte distribuída, você pode trabalhar não apenas com repositórios locais, mas também com repositórios externos.

Repositórios remotos são versões do seu projeto armazenadas em um servidor externo.

Para trabalhar com repositórios externos, use:

 git remote [<options>] 

Se você clonou os repositórios por meio do URL http, já possui um link para o externo. Caso contrário, você pode adicioná-lo com

 git remote add [<options>] <name> <adres> 

Você pode extrair imediatamente as ramificações externas usando -f, --fetch (você obtém os nomes e o estado das ramificações do repositório externo). Você só pode configurar repositórios para enviar ou receber dados usando --mirror [= (push | fetch)]. Para obter tags, especifique --tags.

Para visualizar repositórios externos conectados, use git remote sem argumentos ou git remote -v para visualizar os endereços para enviar e receber dados do repositório.

Para rastrear ramificações, use git branch -u <rep / br> em que rep é o nome do repositório, br é o nome da ramificação externa e ramificação é o nome da ramificação local. Ou git branch --set-upstream local_br origin / br para indicar qual filial local monitorará a ramificação externa.

Quando sua filial controla uma filial externa, você pode descobrir qual filial (local ou externa) está atrasada ou adiantada e por quantas confirmações. Por exemplo, se após uma confirmação você não executou o git push, sua ramificação estará à frente da confirmação externa por 1 confirmação. Você pode descobrir isso executando o git branch -vv, mas primeiro git fetch [remote-name] (--all para obter atualizações de todos os repositórios) para obter os dados mais recentes de um repositório externo. Para cancelar o rastreamento de ramificação, use git branch --unset-upstream [<local_branch>].

Para baixar dados de um repositório externo, use git pull [rep] [branch]. Se suas ramificações rastrearem externas, não será possível especificá-las ao executar git pull. Por padrão, você receberá dados de todas as ramificações monitoradas.

Para fazer o upload de ramificações para uma nova ramificação, use git checkout -b <novo_branch_name> <rep / ramificação>.

Para enviar dados para o servidor, use

 git push [<rep>] [<br>] 

onde rep é o nome do repositório externo e br é a ramificação local que você deseja enviar. Você também pode usar esta entrada git push origin master: dev. Assim, você carrega sua ramificação principal local para a origem (mas será chamada de dev). Você não poderá enviar dados para um repositório externo se não tiver permissão para fazê-lo. Além disso, você não poderá enviar dados para uma ramificação externa se ela estiver à frente da sua (em geral, você pode enviar usando -f, --forse, neste caso, você reescreverá o histórico no repositório externo). Você pode omitir o nome da filial se a filial estiver rastreando o exterior.

Para excluir ramificações externas, use

 git push origin --delete branch_name 

Para obter informações detalhadas sobre o repositório externo (endereços para envio e recebimento, como indicado pelo HEAD, ramificações externas, ramificações locais configuradas para git pull e links locais configurados para git push)

 git remote show <remote_name> 

Para renomear o nome do repositório externo, use

 git remote rename <last_name> <new_name> 

Para remover links para um repositório externo, use

 git remote rm <name> 

3. Ramificação no git

A ramificação é uma ferramenta poderosa e um dos principais recursos do git, pois permite criar e alternar rapidamente entre diferentes ramificações do seu repositório. O principal conceito de ramificação é que você pode decolar da linha principal de desenvolvimento e continuar trabalhando independentemente, sem interferir na linha principal. Um ramo sempre aponta para o último commit nele, e HEAD aponta para o ramo atual (consulte Ponteiros no git ).

3.1 Operações básicas

Para criar uma ramificação, use

 git branch <branch_name> [<start_commit>] 

Aqui branch_name é o nome para o novo branch e start_commit é o commit para o qual o branch apontará (ou seja, o último commit nele). Por padrão, a ramificação estará na última confirmação da ramificação pai.

Opções de ramificação do Git:

• -r -a [--merged | --no-merged] — -r. -a. --merged. --no-merged.
• -l, -f <-> [<->] — -l. , -f. < >.
• -r (-d | -D) — -r. -d. ( ) -D.
• -m | -M [< >] < > — / (-m). / , -M.
• (- | -) [<->] <-> — -c. , -C.
• -v, -vv - Lista de ramificações com o último commit na ramificação -v. Lista e status de ramificações monitoradas com a última confirmação para elas.

Veja git branch -h para mais informações | --ajuda.

Para alternar para uma ramificação, use git checkout. Você também pode criar uma ramificação executando git checkout -b <branch>.

3.2 Mesclar filiais

Para mesclar 2 ramificações de um repositório git, use git merge.

Opções úteis para o git merge:

• --squash - Crie um commit em vez de mesclar. Se houver um conflito nas ramificações, depois de resolvê-lo, você terá 2 confirmações adicionadas na ramificação (confirmação da ramificação mesclada + confirmação de mesclagem), mas ao especificar esse argumento, você adicionará apenas uma confirmação (confirmação mesclada).
• --ff-only - não faça a mesclagem se houver um conflito. Que mais alguém resolva conflitos: D
• -X [estratégia] - Use a estratégia de mesclagem selecionada.
• --abort - Cancela a mesclagem.

O processo de fusão.
Se você não executou novas confirmações na ramificação pai, a mesclagem se reduz ao avanço rápido, como se você não estivesse criando uma nova ramificação, e todas as alterações ocorreram aqui (na ramificação pai).

Se você fez confirmações nos dois ramos, mas não criou um conflito, a mesclagem ocorrerá na "estratégia recursiva", ou seja, você só precisará criar uma consolidação de mesclagem para aplicar as alterações (use a opção --squash para evitar a criação de uma consolidação extra) .
Se você fez confirmações nos dois ramos que fizeram alterações diferentes na mesma parte do mesmo arquivo, será necessário resolver o conflito e confirmar a confirmação de mesclagem.

Ao resolver o conflito, você precisa escolher qual parte das alterações dos dois ramos que deseja sair. Quando você abre um arquivo conflitante, ele contém o seguinte:
<<<<<<< HEAD
Haverá uma versão do último commit do ramo atual
======
Haverá uma versão do último commit do ramo mesclado
>>>>>>> Aqui está o nome ramos com os quais nos fundimos

Após resolver o conflito, você deve concluir a mesclagem ao confirmar.

Durante um conflito, você pode ver quais diferenças existem em quais arquivos.
git diff --ours - Diferença antes da mesclagem e depois
git diff - deles - Diferença da ramificação mesclada antes da mesclagem e após
git diff --base - Diferença com ambas as ramificações antes da mesclagem e após

Se você não deseja permitir a mesclagem, use várias estratégias de mesclagem, escolhendo a versão "nossa" (ou seja, a localizada na ramificação atual) ou escolhendo a versão "deles" localizada na ramificação mesclada sem corrigir o conflito. Execute git merge --Xours ou git merge --Xtheirs, respectivamente.

3.3 Rerere

Rerere - “reutilizar a resolução gravada” - “reutilizar as resoluções de conflito salvas”. O mecanismo de reencaminhamento é capaz de lembrar como você resolveu uma certa parte do conflito no passado e corrige automaticamente o conflito na próxima vez que ele ocorrer.

Para habilitar o reerere do

 git config --global rerere.enabled true 

Você também pode ativar o re-redirecionamento criando o diretório .git / rr-cache no repositório desejado.

Use o status git rerere para ver quais arquivos rerere salvaram instantâneos antes de mesclar.

Use git rerere diff para visualizar o estado atual do conflito.

Se durante a mesclagem diz: Resolvido 'nameFile' usando a resolução anterior. Portanto, o rerere já resolveu o conflito usando o cache.

Para cancelar a resolução automática de conflitos, use git checkout --conflict = merge para cancelar a resolução automática de conflitos e retornar os arquivos ao estado de conflito para resolução manual.

4. Ponteiros no git

O git tem ponteiros como o ramo HEAD. De fato, tudo é muito simples, o HEAD aponta para o ramo atual e o ramo aponta para o último commit nele. Mas, para entender, é melhor imaginar que HEAD indica o último commit.

4.1 Movendo ponteiros

O livro Pro git fornece um exemplo muito bom de como você pode gerenciar seu repositório, por isso também o farei. Imagine o Git gerenciando o conteúdo de três árvores diferentes. Aqui, "árvore" se refere a um "conjunto de arquivos".
Em suas operações habituais, o Git gerencia três árvores:

• CABEÇA - Instantâneo da última confirmação, pai da próxima
• Índice - Instantâneo da próxima confirmação futura
• Diretório de Trabalho - Sandbox

Na verdade, o git fornece ferramentas para manipular as três árvores. A seguir, o comando git reset será discutido, o que permite trabalhar com três árvores do seu repositório.

Usando as várias opções deste comando, você pode:

• --soft - Redefinir apenas HEAD
• --mixed - Redefine o HEAD e o índice
• --hard - Redefine HEAD, índice e diretório de trabalho

Por redefinição significa mover para o commit especificado. O padrão é --mixed.

Exemplo 1. Você fez três confirmações extras, cada uma das quais traz pequenas alterações e deseja fazer uma delas, para que você possa usar o git reset --soft para mover o ponteiro HEAD enquanto deixa o índice e o diretório de trabalho intocados e confirmados. Como resultado, sua história se parecerá com todas as alterações ocorridas em um commit.

Exemplo 2. Você adicionou arquivos extras ao índice e deseja removê-los de lá. Você pode usar o git reset HEAD <arquivos ...> para isso. Ou você deseja que os arquivos de confirmação pareçam duas confirmações de volta. Como eu disse anteriormente, você pode redefinir o índice para qualquer confirmação, ao contrário do git restore, que é redefinido apenas até a última confirmação. Somente com a opção mista você pode aplicar uma ação ao arquivo especificado!

Exemplo 3. Você começou a trabalhar em um novo recurso em seu projeto, mas de repente o empregador diz que não é mais necessário e, em um acesso de raiva, você executa o git reset - retornando seu índice, arquivos e HEAD quando você não começou a trabalhar no recursos. E no dia seguinte, você será informado de que o recurso ainda deve ser reduzido. Mas o que fazer? Como avançar, porque você retrocedeu todas as três árvores e agora não pode encontrá-las no histórico usando o git log. E existe uma solução - este é o log de link do git reflog. Com este comando, você pode ver para onde o HEAD estava apontando e ele se moverá não apenas para baixo no histórico de confirmação, mas também para cima. Este log é local para cada usuário.

Em geral, acho que você pode apresentar muito mais exemplos do que eu. Em conclusão, posso dizer que, com o git reset, você pode fazer mágica ...

5.

1. Pro git — Scott Chacon
2. Git — . , ,
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Git (2016) — .
14. A Hacker's Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby