🗝️

Gitコマンド入門::領域のイメージ図「第六回」

9 min read

やや、遅れた感もありますが、イメージ図を作成!

ここまでの復習を理解度も含めて、gitコマンドの環境を具体的にイメージできるように、図を作成してみましたのでどうぞ! どうでしょうか? みなさんはこのような図をイメージ出来ましたか? なんでもそうですけど図でイメージできるようになると理解度も深まりますね。

git以外でも、全体像をまとめたりする時は、是非、図を起こしましょう! そうすることによって、更にイメージが湧いてくるものなんですよね~(笑)

ちなみに前回「第五回」の記事は、こちらです!

https://zenn.dev/shiozumi/articles/841732f8f8f012

ワンポイント::開発運用時に置いての、restore のキモ?!

実際の開発中のトラブルで起こる中で最悪なのは原因不明のトラブル。以前のバージョンに戻したい。安全に、しかも確実にできるかどうか? 割とあるんですよね、とりあえず、昨日まで正常に動作していたバージョンに戻して、ほっと一息つきたいところ、そういう観点から、やっぱり、restore はしっかり身に着けたいコマンドなんですよね~(苦笑)前に進むことも大切ですが、後ろに戻る事も柔軟に出来ないとね~


図をじっと見ていたら、疑問が湧いてきました~

git restore と、git restore --staged この2つを比較すると、実はデフォルトでのコマンドスイッチの省略形が隠れていることが想像できますよね~
勝手に想像すると、git restore --working って、本当は書くのでは?[1]

早速、コマンド入力で、git restore --help を付けて入力してみましょう!

[shiozumi@ovs-009 mygit]$ git restore --help

SYNOPSIS
  git restore [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>...
  git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [<pathspec>...]
  
OPTIONS
  -s <tree>, --source=<tree>
Restore the working tree files with the content from the given tree. It is common to specify the source tree by naming a commit, branch or tag associated with it.

If not specified, the default restore source for the working tree is the index, and the default restore source for the index is HEAD. When both --staged and --worktree are specified,
  --source must also be specified.

  -p, --patch
Interactively select hunks in the difference between the restore source and the restore location. See the “Interactive Mode” section of git-add(1) to learn how to operate the --patch
mode.

  Note that --patch can accept no pathspec and will prompt to restore all modified paths.

 -W, --worktree, -S, --staged
Specify the restore location. If neither option is specified, by default the working tree is restored. Specifying --staged will only restore the index. Specifying both restores both.

-q, --quiet
   Quiet, suppress feedback messages. Implies --no-progress.

--progress, --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.

--ours, --theirs
  When restoring files in the working tree from the index, use stage #2 (ours) or #3 (theirs) for unmerged paths.

Note that during git rebase and git pull --rebase, ours and theirs may appear swapped. See the explanation of the same options in git-checkout(1) for details.

 -m, --merge
When restoring files on the working tree from the index, recreate the conflicted merge in the unmerged paths.

--conflict=<style>
  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).

--ignore-unmerged
When restoring files on the working tree from the index, do not abort the operation if there are unmerged entries and neither --ours, --theirs, --merge or --conflict is specified.
  Unmerged paths on the working tree are left alone.

--ignore-skip-worktree-bits
In sparse checkout mode, by default is to only update entries matched by <pathspec> and sparse patterns in $GIT_DIR/info/sparse-checkout. This option ignores the sparse patterns and
   unconditionally restores any files in <pathspec>.

--overlay, --no-overlay
In overlay mode, the command never removes files when restoring. In no-overlay mode, tracked files that do not appear in the --source tree are removed, to make them match <tree>
           exactly. The default is no-overlay mode.

// さらに、続くので、、、以下省略

おかあさん、やっと見つかりましたよ!(笑)

こんなにたくさんの機能の中から、--worktree こんな処にいましたね~
git restore [<options>] [--source=<tree>] [--staged] [--worktree]
いやあ~、探すのに苦労するのは行方不明の人もコマンドも似ていて、特にデフォルトでの、隠れオプションは、結構、気が付くのに時間が掛かるものです。そもそも、全体像が見えていませんし、与えられたものを丸暗記で入力している状態では、疑問すら湧いてきませんからね。

では、いつものGoogle先生! 翻訳お願いします!

Google翻訳:
-W、--worktree、-S、--staged
復元場所を指定します。 どちらのオプションも指定されていない場合、デフォルトで作業ツリー[2]が復元されます。 --stagedを指定すると、インデックス[3]のみが復元されます。 両方を指定すると、両方が復元されます。

ん?・・・ちょっとイメージとは違う?

翻訳内容を読んで見ると、両方が指定できるとありますね。ということは、、、

  • git restore // これだと、「Staging -> Working」
  • git restore --staged // これだと、「Repogitory -> Staging」
  • git restore --worktree --staged // これだと、上記の2つの組み合わせ?!
  • git restore --worktree // これだと、git restore と同じですね。

--worktree のみは、git restore と同じですから、一応、お試しください。

--worktree --staged 同時実行は、慎重に理解しないといけませんね。ちょっと、頭がこんがらがってしまってきましたよ・・・

これを同時やるって、順番によって結果が異なります。

いやあ、これはいきなり、難解になりましたね。

  1. git restore --worktree を先に実行して、git restore --staged を実行
  2. git restore --staged を先に実行して、git restore --worktree を実行

当然、この2つでは、結果が異なりますよね。

初期状態がこのようならば・・・[4]

各領域 Working Tree Staging Area Git Repository
ファイル名 README.md README.md README.md
内容 test add (^^) test add test

1番の結果は、以下のように!

各領域 Working Tree Staging Area Git Repository
ファイル名 README.md README.md README.md
内容 test add test test

2番の結果は、全て同じ内容になりますね!

各領域 Working Tree Staging Area Git Repository
ファイル名 README.md README.md README.md
内容 test test test

こうなったら、実際にコマンドを入力して確かめましょう!

それでは、初期状態を作ったら、git status で確認!

On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

このように表示されればOKです。実際のコマンドを忘れてしまった人は、前回を参照!

では、いよいよ! --worktree --staged を実行!

[shiozumi@ovs-009 mygit]$ git restore --worktree --staged README.md

// 結果は、特に何も表示されず・・・

git status で確認!

[shiozumi@ovs-009 mygit]$ git status
On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md // 緑の文字!

どうやら、1番のようです![5]

[shiozumi@ovs-009 mygit]$ cat README.md
# test
# add
各領域 Working Tree Staging Area Git Repository
ファイル名 README.md README.md README.md
内容 test add test test

では、今度は、--worktree のみで!

[shiozumi@ovs-009 mygit]$  git restore --worktree README.md

// 結果は、特に何も表示されず・・・

予測していたどおりなら、Staging から、Working に移動するので、ファイルの中身は、test になる筈ですね!

git status で確認すると、何も変わらず?

[shiozumi@ovs-009 mygit]$ git status
On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md // 緑の文字!

やはり、ファイルの中身が変わっていない?!

[shiozumi@ovs-009 mygit]$ cat README.md
# test
# add

今度は、思い通りの動作ではありません。git restore --worktree のみは、有効ではないのかな? となると、git restore を早速実行してみましょう!

[shiozumi@ovs-009 mygit]$ git restore README.md
[shiozumi@ovs-009 mygit]$ git status
On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

[shiozumi@ovs-009 mygit]$ cat README.md
# test
# add

ガチョーン、><;; またまた、変わらずでしたよ! 大クラッシュ!!・・・ですね。

どうやら、もうひとつのシナリオ?(3番)

各領域 Working Tree Staging Area Git Repository
ファイル名 README.md README.md README.md
内容 test add test add test

git restore --worktree --staged README.md これを実行したときは、この上記の状態になっているようですね。

git status で、modified:README.md が、緑の文字ですから、この状態ですね。完全に読み違えてしまいました。><;; そして、--staged の動作は行われていない(謎?)

今回「第六回」は、ここまで! お疲れ様でした!

https://zenn.dev/shiozumi/articles/2a8f632ca243a3
https://twitter.com/esmile2013
脚注
  1. git restoreも、git restore --worktree も同じ動作です。お試しください! ↩︎

  2. 作業ツリーと、Working treeは、同じです。 ↩︎

  3. インデックスと、Stagin Area は同じです。 ↩︎

  4. テーブルのタイトル名の並びを、図に合わせました。 ↩︎

  5. 後で、気が付きましたが、緑色の文字なので、1番ではありませんでしたね。 ↩︎

Discussion

ログインするとコメントできます