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

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|--ours|--theirs|-m|--conflict=<estilo>] [<tree-ish>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<estilo>] [<tree-ish>] --pathspec-from-file=<arquivo> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​]

DESCRIÇÃO

Atualiza os arquivos na árvore de trabalho para coincidir com a versão no índice ou na árvore informada. Se nenhum "pathspec" seja utilizado, o comando git checkout também atualizará o HEAD para definir o ramo informado 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 início>]

Usando a opção -b faz com que um novo ramo seja criado como se o git-branch[1] fosse chamado e então averiguado. Neste caso utilize as opções --track ou --no-track, para que sejam encaminhadas ao comando git branch. Por questão de conveniência, a opção --track sem -b implica na criação do ramo; consulte a descrição 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>

isto é, a ramificação não é redefinida/criada a menos que "git checkout" seja bem-sucedido.

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

Prepare-se para trabalhar em cima do <commit>, através da desanexação do HEAD (consulte a seção "HEAD DESANEXADO"), atualizando o índice e os arquivos na árvore de trabalho. As alterações locais dos arquivos da árvore de trabalho são mantidas, para que a árvore de trabalho resultante seja a condição registrada no commit, incluindo 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>] [<tree-ish>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<estilo>] [<tree-ish>] --pathspec-from-file=<arquivo> [--pathspec-file-nul]

Substitua o conteúdo dos arquivos que correspondem ao pathspec. Quando o <tree-ish> (na maioria das vezes um commit) não for informado, substitua a árvore de trabalho pelo conteúdo do índice. Quando o `` for informado, substitua o índice e a árvore de trabalho pelo conteúdo em <tree-ish>.

O índice pode conter lançamentos que não foram mesclados, por causa de uma falha durante a mesclagem anterior. É predefinido que caso tente fazer uma averiguação deste lançamento no índice, a operação de averiguação irá falhar e nada será retirado. A utilização da opção -f ignorará estes lançamentos que não foram mesclados. O conteúdo de um lado específico da mesclagem pode ser retirado do índice através do uso da opção --ours ou --theirs. Com a opção -m, as alterações feitas no arquivo da árvore de trabalho podem ser descartadas para recriar o resultado da mesclagem do conflito original.

git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​]

Isto é semelhante ao modo anterior, porém permite usar a interface interativa para exibir o "diff" gerado e escolher quais os blocos utilizar 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 em um 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 as ramificações, continue mesmo se o índice ou a árvore de trabalho forem diferentes do HEAD. Isto é usado para descartar as alterações locais.

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 em um fluxo de trabalho que trata o histórico no ramo remoto como o canônico compartilhado e trata o trabalho realizado no ramo que você está reconstruindo como o trabalho de terceiros que será integrado, e você está assumindo temporariamente o papel do detentor da história canônica durante o "rebase". Como detentor da história canônica, você precisa ver a história do ramo remoto como nossa (ou seja, a "nossa história canônica compartilhada"), enquanto o que você fez do seu lado se ramifica como deles (ou seja, "o trabalho de um colaborador no topo dela ").

-b <novo-ramo>

Crie uma nova ramificação chamada <new_branch> e inicie-a em <start_point>; para mais detalhes consulte git-branch[1].

-B <novo-ramo>

Cria o <novo-ramo> e inicia no <ponto-de-partida>; caso já exista, redefina-o para o <ponto-de-partida>. É o mesmo que executar o comando "git branch" com a opção "-f"; para mais detalhes, consulte git-branch[1].

-t
--track

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

Caso nenhuma opção -b seja utilizada, o nome do novo ramo será derivado do ramo monitorado remotamente, observando a parte local da "refspec" configurada para o ramo remoto correspondente e removendo a parte inicial em seguida para o "*". Isso nos diria para usar um hack como um ramo local ao se ramificar do origin/hack (ou remotes/origin/hack ou até mesmo do refs/remotes/origin/hack). Caso o nome informado não tenha barra ou se a dedução acima resultar em um nome vazio, a dedução será abortada. Em tais casos, é possível dar um nome diretamente usando 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 como 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].

Utilize a opção --no-guess para desativar.

-l

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

--detach

Em vez de averiguar um ramo para trabalhar nele, verifique um commit para a inspeção e para experimentos que sejam descartáveis. Este é o comportamento predefinido do comando git checkout quando `<commit>`não for um nome do ramo. Para obter mais detalhes, consulte a seção "HEAD DESANEXADO" abaixo.

--orphan <novo-ramo>

Crie um novo ramo orphan, chamado <novo-ramo>, iniciado a partir do <ponto-de-partida> e alterne para ele. O primeiro commit feito neste novo ramo não terá pais e será a raiz de um novo histórico totalmente desconectado de todos os outros ramos e commits.

O índice e a árvore de trabalho são ajustadas como se você tivesse rodado o comando git checkout <ponto-de-partida> antes. Isto permite que você inicie um novo histórico que registra um conjunto dos caminhos semelhante ao <ponto-de-partida> através da execução do comando git commit -a para fazer o commit principal.

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.

Caso queira iniciar um histórico desconectado que registre um conjunto dos caminhos totalmente diferentes de um dos <ponto-de-partida>, limpe o índice e a árvore de trabalho logo após criar o ramo órfão executando o comando git rm -rf. Do cume da árvore de trabalho. Depois, você estará pronto para preparar os seus arquivos novos, populando novamente a árvore de trabalho, copiando-os dos outros lugares, extraindo um tarball, 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 fazer a alternância das ramificações, caso haja alterações locais em um ou mais arquivos diferentes entre o ramo atual e o ramo para aonde você está alternando, o comando se recusará a alternar as ramificações, visando preservar as suas alterações dada a circunstância. Contudo, com esta opção, é feita uma mesclagem de três vias entre o ramo atual, o conteúdo da árvore de trabalho e o novo ramo, fazendo com que você esteja neste 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 efetuar a averiguação dos caminhos do índice, essa opção permite recriar a mesclagem conflitante nos caminhos especificados.

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) e diff3 (além do que é exibido através do estilo "merge", exibe os conteúdos originais).

-p
--patch

Selecione blocos de forma interativa com a diferença entre o <tree-ish> (ou o índice, caso não esteja definido) e a árvore de trabalho. Os blocos escolhidos são então aplicados em ordem reversa na árvore de trabalho (e caso um <tree-ish> foi definido, 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 commit gravado no superprojeto. Caso as alterações locais em um submódulo forem sobrescritos, a averiguação falhará, a menos que a opção -f seja utilizado. Caso nada (ou a opção --no-recurse-submodules) seja utilizado, os submódulos que trabalham nas árvores não serão atualizados. Assim como git-submodule[1], isso faz com que o HEAD seja desanexando do submódulo.

--overlay
--no-overlay

No modo predefinido de sobreposição, o git checkout nunca remove os arquivos do índice ou da árvore de trabalho. Ao usar --no-overlay os arquivos que aparecem no índice e na árvore de trabalho, mas não em <tree-ish> são removidos, para fazê-los coincidir exatamente com <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.

<ponto-de-partida>

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.

--

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

<pathspec>…​

Limita os caminhos afetados pela operação.

Para mais detalhes sobre a sintaxe <pathspec>, veja a entrada pathspec em gitglossary[7].

HEAD DESANEXADO

O HEAD normalmente se refere a um determinado ramo (como 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, independente do comando "checkout" utilizado o HEAD agora se refere diretamente ao commit b. Isso é conhecido como uma condição em desanexo (detached ) do HEAD. Simplesmente significa que o HEAD tem referência a um commit em específico em vez de se referir ao nome de um ramo. Vejamos 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   (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. cria uma nova tag foo`com referência ao commit `f deixando HEAD desanexado.

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 há apenas um argumento que não seja -- (como git checkout abc) e quando ambos os argumento <tree-ish> são válidos (como a existência do ramo abc) e <pathspec> também for válido (caso um arquivo ou diretório exista e cujo nome seja "abc" por exemplo), o Git normalmente solicita que você desambigue. Contudo, como fazer o checkout de uma ramificação é uma operação tão comum, o comando git checkout abc considera "abc" nessa situação como <tree-ish>. Utilize git checkout -- <pathspec> caso queira eliminar estes caminhos de dentro do índice.

EXEMPLOS

  1. 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. O arquivo hello.c também será retirado, mesmo que não esteja mais na árvore de trabalho, porque o agrupamento dos arquivos é utilizado para coincidir com as entradas no índice (não na árvore de trabalho pelo shell).

    Caso tenha um ramo chamado hello.c, esta etapa será confundida como uma instrução para alternar para este ramo. Você deve então escrever:

    $ git checkout -- hello.c

  2. 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. 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

    Neste ponto, o comando git diff exibe as alterações mescladas de maneira limpa, como no exemplo anterior, bem como as alterações nos arquivos conflitantes. Edite e resolva o conflito marcando-o como resolvido através do comando git add como de costume:

    $ edit frotz
$ git add frotz

VEJA TAMBÉM

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

GIT

Parte do conjunto git[1]

scroll-to-top