checkout

NAME

git-checkout - Switch branches or restore working tree filesgit-checkout - ブランチの切り替えや作業ツリーファイルの復元

SYNOPSIS概要

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>…​
git checkout [<tree-ish>] [--] <pathspec>…​
git checkout (-p|--patch) [<tree-ish>] [--] [<paths>…​]

DESCRIPTION説明

Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch.作業ツリー内のファイルを、索引内のバージョンまたは指定されたツリーと一致するように更新します。パスが指定されていない場合、git checkoutHEAD指定されたブランチを現在のブランチとして設定するように更新します。

git checkout <branch>

To prepare for working on <branch>, switch to it by updating the index and the files in the working tree, and by pointing HEAD at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the <branch>.<branch>で作業するための準備をするには、作業ツリーのインデックスとファイルを更新し、ブランチでHEADをポイントして、それに切り替えます。作業ツリー内のファイルへのローカルな変更は保持されるので、それらは<branch>にコミットすることができます。

If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to<branch>が見つからなくても、名前が一致する1つのリモート(<remote>と呼びます)にトラッキングブランチが存在する場合は、次のように処理します。

$ git checkout -b <branch> --track <remote>/<branch>

If the branch exists in multiple remotes and one of them is named by the checkout.defaultRemote configuration variable, we’ll use that one for the purposes of disambiguation, even if the <branch> isn’t unique across all remotes. Set it to e.g. checkout.defaultRemote=origin to always checkout remote branches from there if <branch> is ambiguous but exists on the origin remote. See also checkout.defaultRemote in git-config[1].ブランチが複数のリモートに存在し、そのうちの1つがcheckout.defaultRemote構成変数によって名前が付けられている場合、たとえそれが<branch>すべてのリモートにわたって一意でなくても、明確化の目的でそのブランチを使用します。あいまいではあるがリモートの起点に存在するcheckout.defaultRemote=origin場合<branch>は、常にそこからリモートブランチをチェックアウトするように設定します。参照してくださいにはgit-config設定[1] checkout.defaultRemote

You could omit <branch>, in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for the current branch.<branch>を省略することもできます。その場合、コマンドは「現在のブランチをチェックアウトする」ために縮退します。

git checkout -b|-B <new_branch> [<start point>] git checkout -b | -B <新しいブランチ> [<開始ポイント>]

Specifying -b causes a new branch to be created as if git-branch[1] were called and then checked out. In this case you can use the --track or --no-track options, which will be passed to git branch. As a convenience, --track without -b implies branch creation; see the description of --track below.指定する-bと、git-branch [1]が呼び出されてチェックアウトされたかのように、新しいブランチが作成されます。この場合は--trackor --no-trackオプションを使うことができます。これはgit branchに渡されます。便宜上、ブランチの作成--track-b暗示することなく。以下の説明を参照してください--track

If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of-Bが与えられた場合、<new_branch>が存在しなければ作成されます。それ以外の場合はリセットされます。これはトランザクションと同等です。

$ git branch -f <branch> [<start point>]
$ git checkout <branch>

that is to say, the branch is not reset/created unless "git checkout" is successful.つまり、 "git checkout"が成功しない限り、ブランチはリセット/作成されません。

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

Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications.HEADを切り離し(「切り離されたHEAD」セクションを参照)、作業ツリーのインデックスとファイルを更新することによって、<commit>の上で作業する準備をします。作業ツリー内のファイルに対するローカルな変更は保持されるので、結果として生じる作業ツリーはコミットに記録された状態にローカルな変更を加えたものになります。

When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD).<commit>引数がブランチ名の--detach場合は、このオプションを使用して、ブランチの先端でHEADを切り離すことができます(git checkout <branch>HEADを切り離さずにそのブランチをチェックアウトします)。

Omitting <branch> detaches HEAD at the tip of the current branch.<branch>を省略すると、現在のブランチの先端にあるHEADが切り離されます。

git checkout [<tree-ish>] [--] <pathspec>…​ git checkout [<tree-ish>] [ - ] <pathspec>…

Overwrite paths in the working tree by replacing with the contents in the index or in the <tree-ish> (most often a commit). When a <tree-ish> is given, the paths that match the <pathspec> are updated both in the index and in the working tree.作業ツリー内のパスを、インデックスまたは<tree-ish>内の内容に置き換えることによって上書きします(ほとんどの場合コミット)。<tree-ish>が与えられると、<pathspec>に一致するパスがインデックスと作業ツリーの両方で更新されます。

The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result.前回の失敗したマージのため、インデックスにはマージされていないエントリが含まれる可能性があります。デフォルトでは、インデックスからそのようなエントリをチェックアウトしようとすると、チェックアウト操作は失敗し、チェックアウトは行われません。を使用-fすると、これらのマージされていないエントリは無視されます。マージの特定の側からのコンテンツは、--oursまたはを使用してインデックスからチェックアウトできます--theirs。では-m、作業ツリーファイルに加えられた変更を破棄して、元の競合したマージ結果を再作成することができます。

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

This is similar to the "check out paths to the working tree from either the index or from a tree-ish" mode described above, but lets you use the interactive interface to show the "diff" output and choose which hunks to use in the result. See below for the description of --patch option.これは、前述の「インデックスモードまたはツリー風モードから作業ツリーへのパスをチェックアウトする」モードに似ていますが、対話型インターフェイスを使用して「diff」出力を表示し、使用するハンクを選択できます。結果。--patchオプションの説明については、以下を参照してください。

OPTIONSオプション

-q
--quiet - 静か

Quiet, suppress feedback messages.静かで、フィードバックメッセージを抑制します。

--[no-]progress - 進捗状況

Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified. This flag enables progress reporting even if not attached to a terminal, regardless of --quiet.--quiet指定されていない限り、進行状況は端末に接続されたときにデフォルトで標準エラーストリームに報告されます。このフラグは、に関係なく、端末に接続されていなくても進捗レポートを有効にし--quietます。

-f
--force - 力

When switching branches, proceed even if the index or the working tree differs from HEAD. This is used to throw away local changes.分岐を切り替えるときは、インデックスまたは作業ツリーがHEADと異なる場合でも続行します。これはローカルの変更を捨てるために使われます。

When checking out paths from the index, do not fail upon unmerged entries; instead, unmerged entries are ignored.インデックスからパスをチェックアウトするとき、マージされていないエントリに失敗しないでください。代わりに、マージされていないエントリは無視されます。

--ours - 私たちのもの
--theirs - 彼ら

When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths.インデックスからのパスをチェックアウトする場合、ステージ#2(チェックアウト私たち)または#3(彼らがマージされていないパスについて)。

Note that during git rebase and git pull --rebase, ours and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirs gives the version from the branch that holds your work that is being rebased.git rebaseandの間にgit pull --rebase私たちのもの彼らのものは入れ替わって見えるかもしれないことに注意してください。--ours変更がリベースさ--theirsれたブランチからのバージョンを与え、リベースされているあなたの作業を保持しているブランチからのバージョンを与えます。

This is because rebase is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase. As the keeper of the canonical history, you need to view the history from the remote as ours (i.e. "our shared canonical history"), while what you did on your side branch as theirs (i.e. "one contributor’s work on top of it").これはrebase、リモートの履歴を共有された正規のものとして扱い、リベースしているブランチで行われた作業を統合されるサードパーティの作業として扱い、一時的にの役割を引き受けているワークフローで使用されるためです。リベース中の正規の歴史のキーパー。標準的な歴史のキーパーとして、あなたはリモートからの歴史ours(すなわち「私たちの共有された標準的な歴史」)を見る必要がありますtheirs

-b <new_branch> -b <新しいブランチ>

Create a new branch named <new_branch> and start it at <start_point>; see git-branch[1] for details.<new_branch>という名前の新しいブランチを作成し、それを<start_point>から開始します。詳細はgit-branch [1]を見てください。

-B <new_branch> -B <新しいブランチ>

Creates the branch <new_branch> and start it at <start_point>; if it already exists, then reset it to <start_point>. This is equivalent to running "git branch" with "-f"; see git-branch[1] for details.ブランチ<new_branch>を作成し、それを<start_point>から開始します。すでに存在する場合は、<start_point>に再設定してください。これは、 " - g"で "git branch"を実行するのと同じです。詳細はgit-branch [1]を見てください。

-t
--track - トラック

When creating a new branch, set up "upstream" configuration. See "--track" in git-branch[1] for details.新しいブランチを作成するときは、「アップストリーム」設定をセットアップしてください。詳細はgit-branch [1]の "--track" を参照してください。

If no -b option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*". This would tell us to use "hack" as the local branch when branching off of "origin/hack" (or "remotes/origin/hack", or even "refs/remotes/origin/hack"). If the given name has no slash, or the above guessing results in an empty name, the guessing is aborted. You can explicitly give a name with -b in such a case.-bオプションが指定されていない場合は、対応するリモート用に設定されている参照仕様のローカル部分を調べ、最初の部分を "*"まで削除することによって、新しいブランチの名前がリモート追跡ブランチから派生します。これは、 "origin / hack"(または "remotes / origin / hack"、あるいは "refs / remotes / origin / hack")から分岐するときに "hack"をローカルブランチとして使うように指示します。指定された名前にスラッシュがない場合、または上記の推測によって空の名前が返された場合、推測は中止されます。-bそのような場合には明示的に名前を付けることができます。

--no-track

Do not set up "upstream" configuration, even if the branch.autoSetupMerge configuration variable is true.branch.autoSetupMerge構成変数がtrueであっても、「アップストリーム」構成をセットアップしないでください。

-l

Create the new branch’s reflog; see git-branch[1] for details.新しいブランチのreflogを作成してください。詳細はgit-branch [1]を見てください。

--detach

Rather than checking out a branch to work on it, check out a commit for inspection and discardable experiments. This is the default behavior of "git checkout <commit>" when <commit> is not a branch name. See the "DETACHED HEAD" section below for details.作業するためにブランチをチェックアウトするのではなく、検査と破棄可能な実験のためにコミットをチェックアウトします。これは、<commit>がブランチ名ではない場合の "git checkout <commit>"のデフォルトの動作です。詳細については、以下の「切り離されたヘッド」セクションを参照してください。

--orphan <new_branch>

Create a new orphan branch, named <new_branch>, started from <start_point> and switch to it. The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.<start_point>から始まる<new_branch>という名前の新しい孤立ブランチを作成して、それに切り替えます。この新しいブランチに対して行われた最初のコミットは親を持たず、それは他のすべてのブランチやコミットから完全に切り離された新しい履歴の根本となります。

The index and the working tree are adjusted as if you had previously run "git checkout <start_point>". This allows you to start a new history that records a set of paths similar to <start_point> by easily running "git commit -a" to make the root commit.インデックスと作業ツリーは、以前に "git checkout <start_point>"を実行したように調整されます。これにより、 "git commit -a"を実行してルートをコミットすることで、<start_point>に似た一連のパスを記録する新しい履歴を作成できます。

This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish an open source branch of a project whose current tree is "clean", but whose full history contains proprietary or otherwise encumbered bits of code.完全な履歴を公開せずにコミットからツリーを公開したい場合に便利です。現在のツリーは「クリーン」であるが、その全履歴に独自のコードまたはその他のコードの邪魔をするコードが含まれているプロジェクトのオープンソースブランチを公開するには、これを実行することをお勧めします。

If you want to start a disconnected history that records a set of paths that is totally different from the one of <start_point>, then you should clear the index and the working tree right after creating the orphan branch by running "git rm -rf ." from the top level of the working tree. Afterwards you will be ready to prepare your new files, repopulating the working tree, by copying them from elsewhere, extracting a tarball, etc.<start_point>のパスとはまったく異なる一連のパスを記録する切断履歴を開始したい場合は、 "git rm -rf"を実行して孤立ブランチを作成した直後にインデックスと作業ツリーを消去する必要があります。 「作業ツリーの最上位から。その後、新しいファイルを準備し、他の場所からそれらをコピーしてtarballを抽出するなどして、作業ツリーを再作成する準備が整います。

--ignore-skip-worktree-bits

In sparse checkout mode, git checkout -- <paths> would update only entries matched by <paths> and sparse patterns in $GIT_DIR/info/sparse-checkout. This option ignores the sparse patterns and adds back any files in <paths>.疎チェックアウトモードでgit checkout -- <paths>は、$ GIT_DIR / info / sparse-checkout内の<paths>と疎パターンに一致するエントリのみを更新します。このオプションはスパースパターンを無視し、<paths>内のファイルを追加します。

-m
--merge - マージ

When switching branches, if you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context. However, with this option, a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.ブランチを切り替えるときに、現在のブランチと切り替え先のブランチの間で異なる1つ以上のファイルに対するローカルな変更があると、変更内容をコンテキストに保存するために、コマンドはブランチの切り替えを拒否します。ただし、このオプションを使用すると、現在のブランチ、作業ツリーの内容、および新しいブランチの間で3方向のマージが行われ、新しいブランチに移動します。

When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts and mark the resolved paths with git add (or git rm if the merge should result in deletion of the path).マージの競合が発生すると、競合するパスのインデックスエントリはマージされないままになります。競合を解決し、解決されたパスにマークを付ける必要がありますgit add(またはgit rmマージによってパスが削除される場合)。

When checking out paths from the index, this option lets you recreate the conflicted merge in the specified paths.インデックスからパスをチェックアウトするとき、このオプションを使用すると、指定したパスに競合するマージを再作成できます。

--conflict=<style> --conflict = <スタイル>

The same as --merge option above, but changes the way the conflicting hunks are presented, overriding the merge.conflictStyle configuration variable. Possible values are "merge" (default) and "diff3" (in addition to what is shown by "merge" style, shows the original contents).上記の--mergeオプションと同じですが、merge.conflictStyle設定変数を上書きして、競合するハンクの表示方法を変更します。可能な値は "merge"(デフォルト)と "diff3"です( "merge"スタイルで表示されるものに加えて、元の内容を表示します)。

-p
--patch - パッチ

Interactively select hunks in the difference between the <tree-ish> (or the index, if unspecified) and the working tree. The chosen hunks are then applied in reverse to the working tree (and if a <tree-ish> was specified, the index).<tree-ish>(または指定されていない場合はインデックス)と作業ツリーの間の違いから、ハンクを対話的に選択します。選択されたハンクは、作業ツリーとは逆に適用されます(<tree-ish>が指定された場合はインデックス)。

This means that you can use git checkout -p to selectively discard edits from your current working tree. See the “Interactive Mode” section of git-add[1] to learn how to operate the --patch mode.これはgit checkout -p現在の作業ツリーから編集を選択的に破棄するために使用できることを意味します。モードの操作方法については、git-add [1]の「対話モード」の節を参照して--patchください。

--ignore-other-worktrees

git checkout refuses when the wanted ref is already checked out by another worktree. This option makes it check the ref out anyway. In other words, the ref can be held by more than one worktree.git checkout目的の参照が別のワークツリーによってすでにチェックアウトされている場合は拒否されます。このオプションはとにかく参照をチェックアウトさせます。つまり、参照は複数のワークツリーで保持できます。

--[no-]recurse-submodules - [no-] recurse-submodules

Using --recurse-submodules will update the content of all initialized submodules according to the commit recorded in the superproject. If local modifications in a submodule would be overwritten the checkout will fail unless -f is used. If nothing (or --no-recurse-submodules) is used, the work trees of submodules will not be updated. Just like git-submodule[1], this will detach the submodules HEAD.--recurse-submodulesを使用すると、スーパープロジェクトに記録されたコミットに従って、初期化されたすべてのサブモジュールの内容が更新されます。サブモジュール内のローカルな変更が上書きされた場合、チェックアウト-fは使用されない限り失敗します。何も(または--no-recurse-submodules)が使用されていない場合、サブモジュールの作業ツリーは更新されません。git-submodule [1]と同じように、これはサブモジュールHEADを切り離します。

--no-guess - いいえ - 推測

Do not attempt to create a branch if a remote tracking branch of the same name exists.同じ名前のリモート追跡ブランチが存在する場合は、ブランチを作成しないでください。

<branch> <分岐>

Branch to checkout; if it refers to a branch (i.e., a name that, when prepended with "refs/heads/", is a valid ref), then that branch is checked out. Otherwise, if it refers to a valid commit, your HEAD becomes "detached" and you are no longer on any branch (see below for details).チェックアウトへの分岐 もしそれがブランチ(つまり、 "refs / heads /"を前に付けたときに有効なリファレンスである名前)を参照していれば、そのブランチはチェックアウトされます。そうでなければ、それが有効なコミットを参照しているなら、あなたのHEADは "切り離された"状態になり、あなたはもはやどのブランチにもいなくなります(詳細は以下を参照)。

You can use the "@{-N}" syntax to refer to the N-th last branch/commit checked out using "git checkout" operation. You may also specify - which is synonymous to "@{-1}"."@{-N}""git checkout"操作を使ってチェックアウトされたN番目の最後のブランチ/コミットを参照するための構文を使うことができます。-どちらが同意語であるかを指定することもできます"@{-1}"

As a special case, you may use "A...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.特殊なケースとして、あなたは使用すること"A...B"のマージベースのショートカットとしてAかつB正確に一つのマージベースがある場合。次のいずれかせいぜいて残すことができますAし、Bその場合、それがデフォルトに、HEAD

<new_branch>

Name for the new branch.新しいブランチの名前

<start_point> <開始地点>

The name of a commit at which to start the new branch; see git-branch[1] for details. Defaults to HEAD.新しいブランチを開始するコミットの名前。詳細はgit-branch [1]を見てください。デフォルトはHEADです。

<tree-ish> <ツリー>

Tree to checkout from (when paths are given). If not specified, the index will be used.チェックアウト元のツリー(パスが指定されている場合)。指定しない場合は、インデックスが使用されます。

DETACHED HEAD切り離された頭

HEAD normally refers to a named branch (e.g. master). Meanwhile, each branch refers to a specific commit. Let’s look at a repo with three commits, one of them tagged, and with branch master checked out:HEADは通常、名前付きブランチ(例:マスター)を指します。一方、各ブランチは特定のコミットを参照します。3つのコミットがあり、そのうちの1つがタグ付きで、ブランチマスターがチェックアウトしたリポジトリを見てみましょう。

           HEAD (refers to branch 'master')
            |
            v
a---b---c  branch 'master' (refers to commit 'c')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

When a commit is created in this state, the branch is updated to refer to the new commit. Specifically, git commit creates a new commit d, whose parent is commit c, and then updates branch master to refer to new commit d. HEAD still refers to branch master and so indirectly now refers to commit d:この状態でコミットが作成されると、ブランチは新しいコミットを参照するように更新されます。具体的には、git commitは新しいコミットd 作成し、その親はコミットcです。次に、新しいマスターdを参照するようにブランチマスターを更新します。HEADはまだブランチマスターを指しているので間接的にコミットdを指します。

$ edit; git add; git commit
               HEAD (refers to branch 'master')
                |
                v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

It is sometimes useful to be able to checkout a commit that is not at the tip of any named branch, or even to create a new commit that is not referenced by a named branch. Let’s look at what happens when we checkout commit b (here we show two ways this may be done):名前付きブランチの先端にないコミットをチェックアウトしたり、名前付きブランチで参照されていない新しいコミットを作成したりすることができると便利な場合があります。コミットbをチェックアウトしたときに何が起こるかを見てみましょう(ここでは、これが行われる2つの方法を示します)。

$ git checkout v2.0  # or
$ git checkout master^^
   HEAD (refers to commit 'b')
    |
    v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Notice that regardless of which checkout command we use, HEAD now refers directly to commit b. This is known as being in detached HEAD state. It means simply that HEAD refers to a specific commit, as opposed to referring to a named branch. Let’s see what happens when we create a commit:どのチェックアウトコマンドを使用しても、HEADはコミットbを直接参照するようになりました。これは分離HEAD状態にあることとして知られています。これは単に、名前付きブランチを参照するのではなく、HEADが特定のコミットを参照することを意味します。コミットを作成するとどうなるか見てみましょう。

$ edit; git add; git commit
     HEAD (refers to commit 'e')
      |
      v
      e
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

There is now a new commit e, but it is referenced only by HEAD. We can of course add yet another commit in this state:新しいコミットeがありますが、それはHEADによってのみ参照されます。もちろん、この状態でさらに別のコミットを追加することができます。

$ edit; git add; git commit
	 HEAD (refers to commit 'f')
	  |
	  v
      e---f
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

In fact, we can perform all the normal Git operations. But, let’s look at what happens when we then checkout master:実際、私たちはすべての通常のGit操作を実行できます。しかし、次にマスターをチェックアウトしたときに何が起こるかを見てみましょう。

$ git checkout master
               HEAD (refers to branch 'master')
      e---f     |
     /          v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

It is important to realize that at this point nothing refers to commit f. Eventually commit f (and by extension commit e) will be deleted by the routine Git garbage collection process, unless we create a reference before that happens. If we have not yet moved away from commit f, any of these will create a reference to it:この時点でコミットfを参照するものは何もないことを認識することが重要です。それが起こる前に参照を作成しない限り、最終的にコミットf(そして拡張コミットeによって)はルーチンGitガベージコレクションプロセスによって削除されます。まだコミットfから移行していない場合は、これらのいずれかがそれに対する参照を作成します。

$ git checkout -b foo   (1)
$ git branch foo        (2)
$ git tag foo           (3)
  1. creates a new branch foo, which refers to commit f, and then updates HEAD to refer to branch foo. In other words, we’ll no longer be in detached HEAD state after this command.コミットfを参照する新しい分岐fooを作成し、次に分岐fooを参照するようにHEADを更新します。言い換えれば、このコマンドの後、分離HEAD状態にはなりません。

  2. similarly creates a new branch foo, which refers to commit f, but leaves HEAD detached.同様に、コミットfを参照する新しいブランチfooを作成しますが、HEADは切り離したままにします。

  3. creates a new tag foo, which refers to commit f, leaving HEAD detached.新しいタグfooを作成します。これは、コミットfを参照し、HEADを切り離したままにします。

If we have moved away from commit f, then we must first recover its object name (typically by using git reflog), and then we can create a reference to it. For example, to see the last two commits to which HEAD referred, we can use either of these commands:コミットfから移行した場合は、まずそのオブジェクト名を(通常はgit reflogを使用して)回復する必要があります。その後、それに対する参照を作成できます。たとえば、HEADが参照した最後の2つのコミットを確認するには、次のいずれかのコマンドを使用できます。

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

ARGUMENT DISAMBIGUATION引数の区別

When there is only one argument given and it is not -- (e.g. "git checkout abc"), and when the argument is both a valid <tree-ish> (e.g. a branch "abc" exists) and a valid <pathspec> (e.g. a file or a directory whose name is "abc" exists), Git would usually ask you to disambiguate. Because checking out a branch is so common an operation, however, "git checkout abc" takes "abc" as a <tree-ish> in such a situation. Use git checkout -- <pathspec> if you want to checkout these paths out of the index.引数が1つしかない場合--(例: "git checkout abc")、引数が有効<tree-ish>(例:ブランチ "abc"が存在する場合)と有効<pathspec>(例:名前が"abc"が存在します)、Gitは通常あなたに曖昧さを解消するように頼みます。しかし、ブランチをチェックアウトすることはとても一般的な操作なので、 "git checkout abc"は<tree-ish>そのような状況では "abc"を取ります。git checkout -- <pathspec>これらのパスをインデックスからチェックアウトする場合に使用します。

EXAMPLES

  1. The following sequence checks out the master branch, reverts the Makefile to two revisions back, deletes hello.c by mistake, and gets it back from the index.次のシーケンスはmasterブランチをチェックアウトし、Makefile2つのリビジョンに戻して、誤ってhello.cを削除し、そしてインデックスからそれを取り戻します。

    $ git checkout master             (1)
    $ git checkout master~2 Makefile  (2)
    $ rm -f hello.c
    $ git checkout hello.c            (3)
    1. switch branch分岐を切り替える

    2. take a file out of another commit別のコミットからファイルを取り出す

    3. restore hello.c from the indexインデックスからhello.cを復元します。

    If you want to check out all C source files out of the index, you can sayインデックスからすべての Cソースファイルをチェックアウトしたい場合は、

    $ git checkout -- '*.c'

    Note the quotes around *.c. The file hello.c will also be checked out, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).周りの引用符に注意してください*.c。ファイルはhello.c、ファイルグロブは(シェルでないワーキングツリー内の)インデックス内のエントリを一致させるために使用されるためにも、それは作業ツリーにはもはやであっても、チェックアウトされません。

    If you have an unfortunate branch that is named hello.c, this step would be confused as an instruction to switch to that branch. You should instead write:名前の付いた不幸なブランチがある場合hello.c、このステップはそのブランチに切り替えるための指示と混同されるでしょう。代わりに次のように書きます。

    $ git checkout -- hello.c
  2. After working in the wrong branch, switching to the correct branch would be done using:間違ったブランチで作業した後は、正しいブランチへの切り替えは次のようにして行われます。

    $ git checkout mytopic

    However, your "wrong" branch and correct "mytopic" branch may differ in files that you have modified locally, in which case the above checkout would fail like this:しかしながら、あなたの "間違った"ブランチと正しい "mytopic"ブランチはあなたがローカルに修正したファイルで異なるかもしれません、その場合上記のチェックアウトはこのように失敗するでしょう:

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

    You can give the -m flag to the command, which would try a three-way merge:-mフラグをコマンドに与えることができます、それは3者間マージを試みるでしょう:

    $ git checkout -m mytopic
    Auto-merging frotz

    After this three-way merge, the local modifications are not registered in your index file, so git diff would show you what changes you made since the tip of the new branch.この3者間マージの後、ローカルの変更はインデックスファイルに登録されません。そのためgit diff、新しいブランチの先端以降に行った変更が表示されます。

  3. When a merge conflict happens during switching branches with the -m option, you would see something like this:この-mオプションでブランチを切り替える際にマージ競合が発生すると、次のようになります。

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

    At this point, git diff shows the changes cleanly merged as in the previous example, as well as the changes in the conflicted files. Edit and resolve the conflict and mark it resolved with git add as usual:この時点git diffで、前の例のように明確にマージされた変更と、競合したファイルの変更が表示されます。競合を編集して解決しgit add、通常どおりに解決済みとしてマークします。

    $ edit frotz
    $ git add frotz

GIT

Part of the git[1] suite一部のgit [1]スイート

関連記事

スポンサーリンク

COT関数 コタンジェント

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る