Git 🌙
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-checkout last updated in 2.44.0

NOME

git-checkout - Alterne entre os ramos ou restaure os arquivos da árvore de trabalho

RESUMO

git checkout [-q] [-f] [-m] [<ramo>]
git checkout [-q] [-f] [-m] --detach [<ramo>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <novo-ramo>] [<ponto-de-partida>]
git checkout [-f] <tree-ish> [--] <pathspec>…​
git checkout [-f] <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<estilo>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<estilo>] --pathspec-from-file=<arquivo> [--pathspec-file-nul]
git checkout (-p|--patch) [<árvore>] [--] [<pathspec>…​]

DESCRIÇÃO

Atualiza os arquivos na árvore de trabalho para que correspondam à versão no índice ou na árvore determinada. Se nenhum "pathpec" for fornecido, o comando git checkout também atualizará o HEAD para definir o ramo especificado como o ramo atual.

git checkout [<ramo>]

Para se preparar para trabalhar em um <ramo>, alterne para ele atualizando o índice, os arquivos na árvore de trabalho e apontando para o HEAD do ramo. As modificações locais são mantidas nos arquivos da árvore de trabalho, para que o commit possa ser no <ramo>.

Caso o <ramificação> não seja encontrada mas exista uma monitorada remotamente (chame-o de <remoto>) com um nome que coincida e quando --no-guess não seja utilizado, trate-o como um equivalente a

$ git checkout -b <ramo> --track <remoto>/<ramo>

Você pode omitir o <ramo> no caso em que o comando se degenera para "verificar o branch atual", que é um glorificado não-op com efeitos colaterais bastante dispendiosos para exibir apenas as informações de rastreamento, caso existam, para o ramo atual.

git checkout -b|-B <new-branch> [<ponto-de-partida>]

Ao especificar a opção -b, isso faz com que um novo ramo seja criado como se o git-branch[1] tivesse sido invocado e, em seguida, feito o "check-out". Nesse caso, você pode usar as opções --track ou --no-track, que serão encaminhadas ao git branch. Por conveniência, a opção --track sem -b implica na criação de ramificações; consulte a descrição de da opção --track abaixo.

Caso a opção -B seja utilizada, então um <novo-ramo> é criado caso ainda não exista, senão, será redefinido. Este é o equivalente transacional do

$ git branch -f <ramo> [<ponto-de-partida>]
$ git checkout <ramo>

Ou seja, o ramo não é redefinido/criado a menos que o comando "git checkout" seja bem-sucedido (quando o ramo está em uso em outra árvore de trabalho, não apenas o ramo atual permanece o mesmo, mas o ramo também não é redefinido para o ponto inicial por exemplo).

git checkout --detach [<ramo>]
git checkout [--detach] <commit>

Prepare-se para trabalhar em cima do <commit>, desvinculando o HEAD dele (consulte a seção "HEAD DESANEXANDO"), atualizando o índice e os arquivos na árvore de trabalho. As modificações locais nos arquivos da árvore de trabalho são mantidas, de modo que a árvore de trabalho resultante será o estado registrado no commit mais as alterações locais.

Quando o argumento <commit> é um nome de ramificação a opção --detach pode ser utilizada para desanexar o HEAD na ponta do ramo (git checkout <ramo> verificaria aquela ramificação sem desanexar o HEAD).

Ao omitir o <ramo> isso desanexa o HEAD na ponta do ramo atual.

git checkout [-f|--ours|--theirs|-m|--conflict=<estilo>] [<árvore>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<estilo>] [<árvore>] --pathspec-from-file=<arquivo> [--pathspec-file-nul]

Substitui o conteúdo dos arquivos que correspondem ao pathpec. Quando o <tree-ish> (geralmente um commit) não for fornecido, substitua a árvore de trabalho pelo conteúdo do índice. Quando o <tree-ish> for fornecido, substitua o índice e a árvore de trabalho pelo conteúdo do <tree-ish>.

O índice pode conter entradas não mescladas devido a uma falha anterior de mesclagem. É predefinido que se você tentar fazer o "check-out" de uma entrada deste tipo no índice, a operação de "check-out" falhará e nada será verificado. O uso de -f ignorará essas entradas não mescladas. O conteúdo de um lado específico da mesclagem pode ser verificado fora do índice usando a opção --ours ou --theirs. Com a opção -m, as alterações que forem feitas no arquivo da árvore de trabalho podem ser descartadas para recriar o resultado conflitante original da mesclagem.

git checkout (-p|--patch) [<árvore>] [--] [<pathspec>…​]

Esse modo é semelhante ao anterior, mas permite que você use a interface interativa para mostrar a saída do "diff" e escolher quais blocos usar no resultado. Veja abaixo a descrição da opção --patch.

OPÇÕES

-q
--quiet

Silencioso, suprima as mensagens de feedback.

--progress
--no-progress

A condição do progresso é relatado no fluxo de erro predefinido ao estar conectado num terminal, a menos que as opções --quiet seja utilizados. Esta opção ativa os relatórios de progresso, mesmo que não estejam anexados a um terminal, independentemente da opção --quiet.

-f
--force

Ao alternar de ramo, prossiga mesmo que o índice ou a árvore de trabalho seja diferente de HEAD e mesmo que haja arquivos não rastreados no caminho. Isto é usado para descartar alterações locais e quaisquer arquivos ou diretórios não rastreados que estejam no caminho.

Ao verificar os caminhos do índice, não falhe em entradas não mescladas; Em vez disso, as entradas não mescladas são ignoradas.

--ours
--theirs

Ao verificar os caminhos do índice, confira o estágio #2 (nosso) ou #3 (deles) para paths não mesclados.

Observe que durante o git rebase e o git pull --rebase, o ours (nosso) e o theirs (deles) podem aparecer trocados; --ours informa a versão do ramo onde as alterações são feitas, enquanto --theirs informa a versão do ramo que contém o seu trabalho que está sendo feito o "rebase".

Isso ocorre porque o rebase é usado num fluxo de trabalho que trata o histórico no ramo remoto como um canônico compartilhado e trata o trabalho feito no ramo que você está fazendo o "rebase" como o trabalho de terceiros que ainda será integrado, e você está assumindo temporariamente a função de guardião do histórico canônico durante o processo de "rebase". Como guardião do histórico canônico, você precisa ver o histórico do ramo remoto como ours "nosso" (ou seja, "nosso histórico canônico compartilhado"), enquanto o que você fez no seu ramo secundário como theirs "deles" (ou seja, "o trabalho de um colaborador sobre ele").

-b <novo-ramo>

Crie uma nova ramificação chamada <-novo-ramo>, inicie-a em <ponto-de-partida>; e verifique o ramo criado; para obter mais detalhes consulte git-branch[1].

-B <novo-ramo>

Cria a ramificação <novo-ramo>, iniciando-a em <ponto-de-partida>; caso já exista, será redefinido para <ponto-de-partida>. E, em seguida, verifique o ramo resultante. Isso equivale a executar o comando "git branch" com a opção "-f" seguido pelo comando "git checkout" desse ramo; para mais detalhes consulte git-branch[1].

-t
--track[=(direct|inherit)]

Durante a criação de um novo ramo, defina a configuração do "upstream". Para mais detalhes, consulte "--track" em git-branch[1].

Se nenhuma opção -b for usada, o nome do novo ramo será derivado do ramo remotamente rastreado, observando a parte local do refspec configurado para o ramo remoto correspondente, e em seguida, removendo a parte inicial até o "*". Isso nos diria para usar hack como a ramificação local ao ramificar a partir de origin/hack (ou remotes/origin/hack, ou mesmo refs/remotes/origin/hack). Se o nome informado não tiver barra, ou se a adivinhação acima resultar num nome vazio, a adivinhação será abortada. Nesse caso, você pode informar de forma explícita um nome com a opção -b.

--no-track

Não configure "upstream" mesmo que a variável de configuração branch.autoSetupMerge seja verdadeira.

--guess
--no-guess

Caso o <ramo> não seja encontrado mas exista uma ramificação de rastreamento exatamente em uma localidade remota (chame-o <remoto>) que coincida com um nome, trate como equivalente a

$ git checkout -b <ramo> --track <remoto>/<ramo>

Caso o ramo exista em diversos ramos remotos e um deles seja nomeado pela variável de configuração checkout.defaultRemote, para propósitos de desambiguação, mesmo que <ramo> não seja o único em todos os outros ramos remotos. Defina por exemplo, checkout.defaultRemote=origin para que sempre verifique as ramificações remotas de lá caso <ramo> seja ambíguo e ainda assim origin exista. Consulte também checkout.defaultRemote em git-config[1].

--guess é o comportamento predefinido. Utilize a opção --no-guess para desativá-lo.

O comportamento predefinido pode ser definido através da variável de configuração checkout.guess.

-l

Crie o reflog da nova ramificação; veja git-branch[1] para detalhes.

-d
--detach

Em vez de fazer "check-out" de uma ramificação para trabalhar nela, faça o "check-out" de um commit para inspeção e experimentos descartáveis. Esse é o comportamento padrão do comando git checkout <commit> quando o <commit> não é o nome de um ramo. Para mais detalhes consulte a seção "HEAD DESANEXADO" abaixo.

--orphan <novo-ramo>

Crie uma nova ramificação chamada <novo-ramo>, iniciada em <ponto-de-partida> e mude-se para ela. O primeiro commit feito nesse novo ramo não terá origens e será a raiz de um novo histórico totalmente desconectado de todos os outros ramos e dos outros commits.

O índice e a árvore de trabalho são ajustados como se você tivesse executado anteriormente o comando git checkout <ponto-de-partida>. Isso permite iniciar um novo histórico que registra um conjunto de caminhos semelhantes ao <ponto-de-partida>, executando facilmente o comando git commit -a para fazer o principal commit.

Isso pode ser útil quando você quer publicar a árvore a partir de um commit sem expor o seu histórico completo. Você pode fazer isso para publicar um ramo de código aberto de um projeto cuja árvore atual esteja "limpa", mas cujo histórico completo contenha pequenos pedaços de código proprietário amontoados.

Se você quiser iniciar um histórico desconectado que registre um conjunto de caminhos totalmente diferente daquele do <ponto-de-partida>, deverá limpar o índice e a árvore de trabalho logo após criar o ramo órfão executando o comando git rm -rf . no cume da árvore de trabalho. Depois disso, você estará pronto para preparar os seus novos arquivos, repovoando a árvore de trabalho, copiando-os de outro lugar, extraindo um arquivo tar, etc.

--ignore-skip-worktree-bits

É predefinido que no modo de averiguação esparsa, apenas as entradas que sejam coincidentes com <pathspec> e com os padrões esparsos em $GIT_DIR/info/sparse-checkout. Esta opção ignora os padrões esparsos e os adiciona de volta nos arquivos em <pathspec>.

-m
--merge

Ao mudar de ramo, se você tiver alterações locais num ou mais arquivos que sejam diferentes entre o ramo atual e o ramo para onde você está se mudando, o comando se recusará a mudar de ramo para preservar as suas alterações dentro do contexto. No entanto, com essa opção, é feita uma mesclagem de três vias entre o ramo atual, o conteúdo da sua árvore de trabalho e o novo ramo, e você estará no novo ramo.

Quando ocorre um conflito durante a mesclagem, as entradas do índice para os caminhos conflitantes não são mesclados, sendo necessário que você resolva os conflitos e marque os caminhos resolvidos com git add (ou git rm caso a mesclagem resulte na exclusão do caminho) .

Ao fazer o "check-out" dos caminhos do índice, essa opção permite recriar a mesclagem conflitante nos caminhos especificados. Essa opção não pode ser usada ao fazer o "check-out" dos caminhos de uma árvore.

Ao alternar as ramificações com --merge as alterações que já foram organizadas podem ser perdidas.

--conflict=<estilo>

O mesmo que a opção --merge acima, porém altera a maneira como os blocos conflitantes são apresentados, ao substituir a variável de configuração merge.conflictStyle. Os valores possíveis são merge (predefinido), "diff3" e "zdiff3".

-p
--patch

Seleciona interativamente os blocos na diferença entre a <tree-ish> (ou no índice, se não for especificado) e a árvore de trabalho. As partes escolhidas são então aplicadas de forma inversa à árvore de trabalho (e se um <tree-ish> foi especificado, o índice).

Isso significa que você pode usar o git checkout -p para descartar seletivamente as edições da sua árvore de trabalho atual. Veja a seção “Interactive Mode” do git-add[1] para aprender como operar o modo --patch.

Observe que por predefinição esta opção usa o modo sem sobreposição (consulte também --overlay), assim como, atualmente também não é compatível com o modo de sobreposição.

--ignore-other-worktrees

O comando git checkout irá se recusar quando a "ref" desejada já tenha sido averiguada através de uma outra árvore de trabalho. Esta opção faz com que ele averigue a "ref" mesmo assim. Em outras palavras, a "ref" pode ser mantida por mais de uma árvore de trabalho.

--overwrite-ignore
--no-overwrite-ignore

Substitua silenciosamente os arquivos ignorados ao alternar ramificações. Este é o comportamento predefinido. Utilize --no-overwrite-ignore para interromper a operação quando o novo ramo contiver os arquivos que foram ignorados.

--recurse-submodules
--no-recurse-submodules

O uso da opção --recurse-submodules atualizará o conteúdo de todos os submódulos ativos de acordo com o commit registrado no superprojeto. Se as alterações locais num submódulo forem substituídas, o "checkout" falhará, a menos que a opção -f seja usada. Se nada (ou --no-recurse-submodules) for usado, as árvores de trabalho dos submódulos não serão atualizados. Assim como o git-submodule[1], isso desanexará o HEAD do submódulo.

--overlay
--no-overlay

No modo de sobreposição padrão, o comando git checkout nunca remove os arquivos do índice ou da árvore de trabalho. Ao especificar a opção --no-overlay, os arquivos que aparecem no índice e na árvore de trabalho, mas não em <tree-ish>, são removidos para que correspondam exatamente a <tree-ish>.

--pathspec-from-file=<arquivo>

O "pathspec" é passado com <arquivo> em vez dos argumentos da linha de comando. Caso o <arquivo> seja exatamente -, a entrada padrão será utilizada. Os elementos do "pathspec" são separados por caracteres de término de linha LF ou CR/LF. Os elementos do "pathspec" podem ser citados conforme explicado na variável de configuração core.quotePath (consulte git-config[1]). Consulte também opção --pathspec-file-nul e o global --literal-pathspecs.

--pathspec-file-nul

Só faz algum sentido caso seja utilizado junto com a opção --pathspec-from-file. Os elementos "pathspec" são separados com caracteres NUL e todos os outros caracteres são considerados de forma literal (incluindo as novas linhas e as citações).

<ramo>

O ramo que será averiguado; caso se referira a um ramo (ou seja, um nome que, quando anexado com "refs/heads/", seja uma "ref" válida), então este ramo será retirado. Caso contrário, caso tenha referência para um commit inválido, o seu HEAD se torna "desanexado" e você não estará mais em qualquer outro ramo (veja mais detalhes abaixo).

Você pode usar a sintaxe @{-N} para se referir ao último ramo/commit finalizado utilizando o comando "git checkout". Também é possível utilizar - que é um sinônimo para @{-1}.

Como um caso especial, você pode usar A...B como um atalho para a mesclagem na base de A e` B` se houver exatamente uma base a ser mesclada. Você pode deixar de fora, no máximo, um de A e` B`, no caso, a predefinição retorna para HEAD.

<novo-ramo>

Nome para o novo branch.

<início-ponto>

O nome do commit onde o ramo deve iniciar; para mais detalhes consulte git-branch[1]. A predefinição retorna para HEAD.

Como um caso especial, é possível utilizar "A...B" como um atalho como uma base para a mesclagem de A e B caso exista exatamente uma base de merge. Você pode deixar de fora, no máximo, um de A e` B`, caso onde a predefinição retorna para HEAD.

<tree-ish>

Árvore que será averiguada (quando os caminhos são informados). Caso não seja informado, o índice será usado.

Como um caso especial, é possível utilizar "A...B" como um atalho como uma base para a mesclagem de A e B caso exista exatamente uma base de merge. Você pode deixar de fora, no máximo, um de A e` B`, caso onde a predefinição retorna para HEAD.

--

Não interprete mais argumentos como opções.

<pathspec>…​

Limita os caminhos afetados pela operação.

Para mais detalhes sobre a sintaxe, consulte a entrada pathspec em gitglossary[7].

HEAD DESANEXADO

O HEAD normalmente se refere a um determinado ramo (por exemplo, master). Enquanto isso, cada ramo se refere a um commit em específico. Vejamos um repositório com três commits, um deles marcado e com o ramo master averiguado:

           HEAD (refere-se ao ramo 'master')
            |
            v
a---b---c  ramo 'master' (refere-se ao commit 'c')
    ^
    |
  tag 'v2.0' (refere-se ao commit 'b')

Quando um commit é criado nest condição, o ramo é atualizado para se referir ao novo commit. Em específico o comando git commit que cria um novo commit d, cujo pai é o commit c, que atualiza o ramo master para ter referência com o novo commit d. O HEAD ainda se refere ao ramo master e agora indiretamente, refere ao commit d:

$ editar; git adicionar; git commit

               HEAD (refere-se ao ramo 'master')
                |
                v
a---b---c---d  ramo 'master' (refere-se ao commit 'd')
    ^
    |
  tag 'v2.0' (refere-se ao commit 'b')

Às vezes, é útil poder fazer a averiguação de um commit que não está no topo de qualquer ramo conhecido ou mesmo para criar um novo commit que não seja referenciado por nenhum outro ramo conhecido. Vejamos o que acontece quando fazemos a averiguação do commit b (aqui exibimos duas maneiras de faze-lo):

$ git checkout v2.0  # ou
$ git checkout master^^

   HEAD (refere-se ao commit 'b')
    |
    v
a---b---c---d  ramo 'master' (refere-se ao commit 'd')
    ^
    |
  tag 'v2.0' (refere-se ao commit 'b')

Observe que, independentemente do comando "checkout" que usamos, HEAD agora se refere diretamente ao commit b. Isso é conhecido como estar no estado HEAD desanexado/desvinculado. Isso significa simplesmente que HEAD se refere a um commit específico, em vez de se referir a um ramo indicado. Vamos ver o que acontece quando criamos um commit:

$ editar; git adicionar; git commit

     HEAD (refere-se ao commit 'e')
      |
      v
      e
     /
a---b---c---d  ramo 'master' (refere-se ao commit 'd')
    ^
    |
  tag 'v2.0' (refere-se ao commit 'b')

Agora existe um novo commit e, porém a sua referência existe apenas no HEAD. Nessa condição fica claro que podemos adicionar mais um commit:

$ editar; git adicionar; git commit

	 HEAD (refere-se ao commit 'f')
	  |
	  v
      e---f
     /
a---b---c---d  ramo 'master' (refere-se ao commit 'd')
    ^
    |
  tag 'v2.0' (refere-se ao commit 'b')

De fato, podemos executar todas as operações normais do Git. Porém vejamos o que acontece quando fazemos um checkout do master:

$ git checkout master

               HEAD (refere-se ao ramo 'master')
      e---f     |
     /          v
a---b---c---d  ramo 'master' (refere-se ao commit 'd')
    ^
    |
  tag 'v2.0' (refere-se ao commit 'b')

É importante perceber que neste momento nada se refere ao commit f. Eventualmente o commit f (e de tabela o commit e) será excluído pelo processo rotineiro da coleta de lixo do Git, antes que isso aconteça é preciso criar uma referência. Se ainda não nos afastamos do commit f, qualquer um deles criará uma referência a ele:

$ git checkout -b foo  # or "git switch -c foo"  (1)
$ git branch foo                                 (2)
$ git tag foo                                    (3)

  1. cria uma nova ramificação foo com referência ao commit f, atualiza HEAD com referência ao ramo foo. Isso significa que agora não estamos mais desanexados do HEAD após este comando.

  2. similarmente cria um novo ramo foo com referência ao commit f deixando HEAD desanexado.

  3. creates a new tag foo, which refers to commit f, leaving HEAD detached.

Se nos afastamos do commit f, primeiro precisamos recuperar o nome do objeto (normalmente utilizando git reflog) e em seguida, podemos criar uma referência para ele. Para ver os dois últimos commits aos quais o HEAD se refere, podemos usar um destes comandos, por exemplo:

$ git reflog -2 HEAD # ou
$ git log -g -2 HEAD

DESAMBIGUAÇÃO DOS ARGUMENTOS

Quando é fornecido apenas um argumento e ele não for -- (git checkout abc por exemplo), e quando o argumento é tanto um <tree-ish> válido (uma ramificação abc existe por exemplo) quanto um <pathspec> válido (um arquivo ou diretório cujo nome é "abc" existe por exemplo), o Git normalmente pede que você faça a desambiguação. No entanto, como o checkout de uma ramificação é uma operação muito comum, em tal situação o comando git checkout abc considera "abc" como um <tree-ish>. Use git checkout -- <pathspec> se quiser fazer o "checkout" desses caminhos fora do índice.

EXEMPLOS

1. Caminhos

A sequência a seguir exclui o ramo master, reverte o` Makefile` para duas revisões anteriores, exclui o arquivo hello.c por engano e faz a recuperação do índice.

$ git checkout master             (1)
$ git checkout master~2 Makefile  (2)
$ rm -f hello.c
$ git checkout hello.c            (3)

  1. alternância do ramo

  2. tirar um arquivo de um outro commit

  3. restaura o arquivo hello.c a partir do índice

Caso queira verificar todos os arquivos "*.c" do código-fonte diretamente do índice, você pode utilizar

$ git checkout -- '*.c'

Observe as aspas em torno de *.c. Também será feito o "checkout" no arquivo hello.c, mesmo que não esteja mais na árvore de trabalho, porque o agrupamento do arquivo é usado para corresponder às entradas no índice (não na árvore de trabalho pelo shell).

Caso tenha a infelicidade de ter um ramo chamado hello.c, essa etapa será confundida como uma instrução para mudar para este ramo. Em vez disso você deve escrever:

$ git checkout -- hello.c

2. Mesclar

Depois de trabalhar no ramo errado, mudar para o ramo correto seria feito utilizando:

$ git checkout mytopic

No entanto, o seu ramo "errado" e o correto "mytopic" podem diferir nos arquivos modificados localmente por você. Que dessa maneira, a verificação acima falhará assim:

$ git checkout mytopic
error: You have local changes to 'frotz'; not switching branches.

Você pode repassar a opção`-m` ao comando, que tentaria uma mesclagem de três vias:

$ git checkout -m mytopic
Auto-merging frotz

Após esta mesclagem de três vias, as alterações locais não serão registradas no seu arquivo do índice, portanto, o git diff exibirá quais foram as alterações feitas desde o cume do novo ramo.

3. Mesclar os conflitos

Quando um conflito de mesclagem acontece durante a troca de branches com a opção -m, você veria algo assim:

$ git checkout -m mytopic
Auto-merging frotz
ERROR: Merge conflict in frotz
fatal: merge program failed

Nesse ponto, o git diff mostra as alterações mescladas de forma limpa, como no exemplo anterior, bem como as alterações nos arquivos em conflito. Edite e resolva o conflito, como de costume, marque-o como resolvido com git add:

$ edit frotz
$ git add frotz

CONFIGURAÇÃO

Warning

Missing pt_BR/includes/cmd-config-section-all.txt

See original version for this content.
Warning

Missing pt_BR/config/checkout.txt

See original version for this content.

VEJA TAMBÉM

git-switch[1], git-restore[1]

GIT

Parte do conjunto git[1]

scroll-to-top