Gitのrestoreコマンドについて調べてみた

はじめに

この記事では、「Gitのrestoreコマンドの基本的な機能と使い方」について書いています。

Gitにはたくさんのコマンドがあり、また自分は普段TortoiseGitを使っていて全然コマンドを覚えてないので、ちゃんと自分でコマンドを試しながら学んでみるべく記事にしました。

自分に向けた備忘録でもありますが、「Gitのコマンドにまだ習熟してない人」や「Gitのresetコマンドがどういうものか知りたい」な人の一助になれば嬉しいです。

restoreコマンドが生まれた背景

restoreコマンドは、指定されたファイルなどを「戻す」ことができるコマンドで、Gitのrestoreコマンドは、バージョン2.23でリリースされた、新しいコマンドです。

変更を戻す操作は元々checkoutコマンドで出来てましたが、このcheckoutは他にも多くの機能を持っていたため、変更を戻す操作のみが出来るコマンドとしてリリースされたそうです。

こういう背景を考えると、そのうちcheckoutコマンドはなくなるかも分かりませんのでrestoreコマンドで変更を戻す操作を行うように今から慣れておくのが良いかもしれません(ただし、restoreコマンドはまだ実験的機能のようなので注意が必要ですが)

ちなみに、restore以外にもswitchコマンド(ブランチの切り替えを行う)も似たような目的で同じバージョンからリリースがされています。

restoreコマンドの使い方

「変更したがステージングしてない段階」を「変更してない」段階に戻す(=復元する)

ファイルを変更してgit addをしてない段階、git statusだとChanges not staged for commit:の項に出てくる状態のファイルの場合、以下のコマンドにて変更を戻すことができます。

git restore <ファイル名>

この時、restore対象のファイルは、変更を加える前の状態に復元されます。

また、以下のようにファイル名の部分を.とすると、該当する全てのファイルの変更を戻すことができます。

git restore .

「ステージングしたがコミットはまだ」な段階を「ステージングしてない」の段階に戻す

ファイルを変更してgit add、まではしたがgit commitは未だしていない段階、git statusだとChanges to be committed:の項に出てくる状態のファイルの場合、以下のコマンドにて変更を戻すことができます。

git restore --staged <ファイル名>

この時、restore対象のファイルは、ステージングする前の段階(git statusだとChanges not staged for commit:の項に出てくる状態) に戻します。

Note

ファイルを変更前に復元するわけではないのでご注意ください(復元したい場合はgit restore --staged <ファイル名>の後にgit restore <ファイル名>を実行する必要があります。

また、以下のようにファイル名の部分を.とすると、該当する全てのファイルの変更を戻すことができます。

git restore --staged .

おわりに

「Gitのrestoreコマンドの基本的な機能と使い方」について解説しました。

機能が少ないと間違った操作の可能性も少なくなるし、名称も、checkoutよりrestoreという方が個人的に分かりやすくて良いと感じました。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

kakakakakku.hatenablog.com

Gitで削除などの変更(ステージング前の段階)を復元する方法

はじめに

この記事では、「Gitで削除などの変更(ステージング前の段階)を復元する方法」について書いています。

git rmでファイルを消した後、そのファイルを復元しようとしても上手くいかずに調べたのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「Gitで削除や編集したファイルを復元したい」な人の一助になれば嬉しいです。

要点だけ

git checkout <ファイル名>またはgit restore <ファイル名>

説明

Note

試した際の環境は以下の通りです。

実験で使うgitのリポジトリは以下のような構成になっており、またリポジトリ内のファイルは全て登録されているものとします。

sample
├ .git
│  └ ...
├ alpha.txt
└ beta.txt

ここから単純にbeta.txtをローカルで削除しただけの状態でスタートしたいと思います。

Note

削除した例で説明してますが、ファイル内を編集したといった変更でも同じ要領で復元する行うことができます。

単純にbeta.txtをローカルで削除しただけの状態でスタートしたいと思います。

この時のリポジトリ(フォルダ)の状態は以下のようにbeta.txtは削除されています。

sample
├ .git
│  └ ...
└ alpha.txt

また、git statusを実行すると次のような出力が得られると思います。

On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    beta.txt

no changes added to commit (use "git add" and/or "git commit -a")

この状態から復元するにはcheckoutコマンドを使用します。

git checkout <ファイル名>

この例だと

git checkout beta.txt

を実行することで削除前の状態に復元することができます。

また、checkoutコマンドの代替として用意されたrestoreコマンドを使って復元することもできます。

git restore <ファイル名>

おわりに

「Gitで削除などの変更(ステージング前の段階)を復元する方法」について解説しました。

誤った処理(特に削除)をしてしまった時、少しテンパってしまいますが復元する方法が分かったので安心して変更を加えていけそうです。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

awesome-linus.com

Gitのrmコマンドを試してみた

はじめに

この記事では、「Gitのrmコマンドの基本」について書いています。

Gitにはたくさんのコマンドがあり、また自分は普段TortoiseGitを使っていて全然コマンドを覚えてないので、ちゃんと自分でコマンドを試しながら学んでみるべく記事にしました。

自分に向けた備忘録の意味もありますが、「Gitのコマンドにまだ習熟してない人」な人の一助になれば嬉しいです。

git rmとはどんなコマンドか

  • git rmとはgitの管理下にあるファイルを削除するコマンドです。
  • git rm <ファイル名>のように記述します。
  • 削除してその変更をインデックス領域に登録する所まで実施してくれます。

説明

では実行時はどういう感じになるのか、実際に試してみましょう

Note

試した際の環境は以下の通りです。

実験で使うgitのリポジトリは以下のような構成になっており、またリポジトリ内のファイルは全て登録されているものとします。

sample
├ .git
│  └ ...
├ alpha.txt
└ beta.txt

さて、この状態のリポジトリからgit rmを実行してみましょう。次のようなコマンドを実行します。

git rm beta.txt

これでbeta.txtが削除されるはずです。

git rm beta.txt実行後の状況を確認してみましょう。

まず、sampleフォルダ(リポジトリ内)を確認するとbeta.txtがなくなっていることが分かるかと思います。

次にgit statusを実行します。

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    beta.txt

Changes to be committed:(インデックス領域に登録され、コミット可能な状態のファイル)にbeta.txtの名前がdeletedであります。削除が正しく行われたようです。

おわりに

「Gitのrmコマンドの基本」について解説しました。

リポジトリはファイルの追加、変更の他に削除したい時も当然あるかと思いますが、そういう時はgit rmコマンドの出番ですのでどんどん活用してみてください。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

magazine.techacademy.jp

Gitで削除などの変更(ステージング後コミット前の段階)を復元する方法

はじめに

この記事では、「Gitで削除などの変更(ステージング後コミット前の段階)を復元する方法」について書いています。

git rmでファイルを消した後、そのファイルを復元しようとしても上手くいかずに調べたのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「Gitで削除や編集したファイルを復元したい」な人の一助になれば嬉しいです。

要点だけ

以下のようにコマンドを実行することで復元できます。

git restore --staged <ファイル名>
git checkout <ファイル名>

実際に試してみる

Note

試した際の環境は以下の通りです。

実験で使うgitのリポジトリは以下のような構成になっており、またリポジトリ内のファイルは全て登録されているものとします。

sample
├ .git
│  └ ...
├ alpha.txt
└ beta.txt

ここからgit rm beta.txtを実行してbeta.txtを削除した状態でスタートしたいと思います。

Note

削除した例で説明してますが、ファイル内を編集したといった変更でも同じ要領で復元する行うことができます。

この時のリポジトリ(フォルダ)の状態は以下のようにbeta.txtは削除されています。

sample
├ .git
│  └ ...
└ alpha.txt

また、git statusを実行すると次のような出力が得られると思います。

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    beta.txt

この状態から削除前の状態へ戻すには、まず下のコマンドを実行してインデックス領域への登録を解除します。

git restore --staged <ファイル名>

この作業を行ってから

git checkout <ファイル名>

を実行します。今回の例だと

git restore --staged beta.txt
git checkout beta.txt

と実行することで復元できました。

Note

git restore ...を行わず(=削除した情報がインデックス領域へ登録されている状態)でgit checkout ...を実行しても、下記のようなエラー文が出てしまいます。

error: pathspec 'beta.txt' did not match any file(s) known to git

なのでgit restore ...を忘れないようにしましょう

おわりに

「Gitで削除などの変更(ステージング後コミット前の段階)を復元する方法」について書いています。」について解説しました。

誤った処理(特に削除)をしてしまった時、少しテンパってしまいますが復元する方法が分かったので安心して変更を加えていけそうです。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

awesome-linus.com

Rustでchronoクレートを試してみた

はじめに

この記事では、「Rustでchronoクレートの概要と基本的な使い方」について書いています。

Rustの勉強の一環として色々なクレートを触ってみようと思い、今回はchronoクレートについて調べてみました。

自分に向けた備忘録でもありますが、「Rustでchronoクレートってどんなもの?」や「Rustで日時などを扱いたい」な人の一助になれば嬉しいです。

chronoクレートとは何か

前提(環境)

以下の環境で実験をしていきます。

chronoクレートを使ってみる

まずはchronoクレートを使えるようにするため、Cargo.tomlに依存関係を追加します。

...(省略)

[dependencies]
chrono = "0.4.23"

現在日時を取得する

現在日時はUTC協定世界時)とローカル時刻の2種類取得することができ、以下のように行います。

    // use chrono::{Local, Utc}; が必要

    // 現在日時(協定世界時 (UTC))を取得する。
    let dt_utc = Utc::now();
    println!("{}", dt_utc);

    // 現在日時(実行しているPCのローカル時刻)を取得する。
    let dt_local = Local::now();
    println!("{}", dt_local);

この時の出力は以下のようになります。

2022-11-13 10:28:40.190246700 +09:00
2022-11-13 01:28:40.193508400 UTC

出力のフォーマットを、例えば「xx年xx月xx日」のようにしたい場合はformatメソッドを使い、

    println!("{}", dt_local.format("%Y年%m月%d日 %H:%M:%S"));

と書くことで実現できます。(詳細は以下のサイトに記載があります)

https://docs.rs/chrono/0.4.6/chrono/format/strftime/index.html

日時に時間を加算減算する

Durationを使うことで実現ができ、以下のように使います。

    // use chrono::{Duration, Local}; が必要

    let dt_local_tomorrow = dt_local + Duration::days(1);
    println!("{}", dt_local_tomorrow);

2つの日時の差を計算する

下記のようにすることで日時の差を計算することもできます。

また、差のは「何日」の形だったり「何時間」の形だったり様々な形式で出力することができます。

    // use chrono::{Duration, Local}; が必要

    let duration: Duration = dt_local_tomorrow - dt_local;

    println!("days: {}", duration.num_days());
    println!("hours: {}", duration.num_hours());

おわりに

「Rustでchronoクレートの概要と基本的な使い方」について解説しました。

chronoクレートを用いることで日時の取得や計算が簡単に行えるようになります。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

https://qnighy.hatenablog.com/entry/2019/04/21/190000

https://qiita.com/fujitayy/items/ae6175118cbed7134594

GitHub Actionsで環境変数を試してみる

はじめに

この記事では、「GitHub Actionsで環境変数とは何か、どう使うのか」について書いています。

GitHub Actionsは様々なことを自動で行わせることができる便利な機能で、色々使えるようになりたいと機能を試しながら勉強した内容を記事にしました。

自分に向けた備忘録でもありますが、「GitHub Actionsで環境変数をよく知らない」や「jobs間などで変数を使いまわしたい」な人の一助になれば嬉しいです。

環境変数ってなに?

とても平たく説明すると「job間やsteps間で共通して使える変数」のようなものです。

例えば「この名前はymlファイル内で何か所も書いてるけど後で変更しやすいように一か所で定義したい」などの時に役に立ちます。

GitHub Actionsでは、GitHub Actiuonsで定義された環境変数もありますが、自分で変数を作って使用することもできます。

簡単な例で環境変数を試してみる

では簡単な例で見てみましょう

name: Action Sample

on:
  workflow_dispatch:

env:
  GREETING: Hello

jobs:
  greet:

    runs-on: ubuntu-latest

    steps:
      - name: ${{env.GREETING}}
        run: echo "Hello World!"

Hello World!を出力するだけのものです。

ポイントは2つで、1つ目は

env:
  GREETING: Hello

GREETINGという環境変数(この中身はHello)を定義していること。そして2つ目は

    steps:
      - name: ${{env.GREETING}}

とnameに環境変数を使用している点です。

環境変数を使用する時は${{env.環境変数名}}と書きます。

(※正確にはymlファイル上で使用する場合であり、bashシェルで使用する場合などはまた書き方が違うのですが、今回は簡単な例で環境変数というものがどんなものかを伝えたいのでそのことには触れません)

こうすることでアクション実行時、nameHelloになります。

では上のコードのアクションを実行させその内容を確認してみましょう。画面は以下のようになります。

赤枠の部分、nameで指定した文字列が表示されますが、環境変数で指定したHelloが表示されているのが分かります。(${{env.GREETING}}とは表示されていません)

おわりに

GitHub Actionsで環境変数とは何か、どう使うのか」について解説しました。

今回は導入として基本的な使い方を説明しましたが、非常に便利ですので是非これをきっかけに公式ドキュメントなどで使い方を学ぼうと思っていただけたら幸いです。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

https://docs.github.com/ja/actions/learn-github-actions/environment-variables

https://book.st-hakky.com/docs/github-actions-environment-variable/

Pythonのpytestで-xオプションを試してみる

はじめに

この記事では、「Pythonでpytestの-xオプションについての概要」について書いています。

私はこれまでpytestを使ったことはほぼなく、pytestの勉強をしていますが、pytestには色々なオプションがあるので、その中の-xオプションについて、どういう機能なのか、実際に使ってみてどうなのかをまとめて記事を書きました。

自分に向けた備忘録の意味もありますが、「pytest使いたいけどよく知らない」な人の一助になれば嬉しいです。

要点: pytest -xは何が出来るの?

  • テストが失敗したら、テストを続けずその場で終了する
  • 失敗した時点で終了する(全てのテストを行わない)のでテスト時間が短縮できる可能性がある

前提(環境)

以下の環境で実験をしていきます。

また、実験で使うフォルダ(ファイル)は以下の通りです。

sample
├ test_add.py
└ test_sub.py

test_add.pyの中身は以下のようになっています。

def test_add1():
        assert 2 == 1 + 2

def test_add2():
        assert 4 == 1 + 3

test_add1()は、テストに失敗するようにしている点にご注意ください

また、test_sub.pyの中身は以下のようになっています。

def test_sub1():
        assert 1 == 2 - 1

def test_sub2():
        assert 2 == 3 - 1

試してみる

ではコマンドを実行してどのような結果が出力されるか確認してみましょう

まずはpytestとオプションをつけずに実行した場合の出力を確認します。

================================================= test session starts =================================================
platform win32 -- Python 3.9.4, pytest-7.1.3, pluggy-1.0.0
rootdir: C:\Users\xxx\sample
plugins: anyio-3.6.1
collected 4 items

test_add.py F.                                                                                                   [ 50%]
test_sub.py ..                                                                                                   [100%]

====================================================== FAILURES =======================================================
______________________________________________________ test_add1 ______________________________________________________

    def test_add1():
>           assert 2 == 1 + 2
E           assert 2 == (1 + 2)

test_add.py:2: AssertionError
=============================================== short test summary info ===============================================
FAILED test_add.py::test_add1 - assert 2 == (1 + 2)
============================================= 1 failed, 3 passed in 0.21s =============================================

計4つあるテストで1つが失敗し3つが成功したと書かれています。

では次に、今回のタイトルにもなっている-xオプションを使い、pytest -xと実行してみましょう

================================================= test session starts =================================================
platform win32 -- Python 3.9.4, pytest-7.1.3, pluggy-1.0.0
rootdir: C:\Users\xxx\sample
plugins: anyio-3.6.1
collected 4 items

test_add.py F

====================================================== FAILURES =======================================================
______________________________________________________ test_add1 ______________________________________________________

    def test_add1():
>           assert 2 == 1 + 2
E           assert 2 == (1 + 2)

test_add.py:2: AssertionError
=============================================== short test summary info ===============================================
FAILED test_add.py::test_add1 - assert 2 == (1 + 2)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
================================================== 1 failed in 0.19s ==================================================

下から2行目に、stopping after 1 failuresと、失敗して停止したことが書かれています。

-xオプションは、テストが失敗したらそこで終了します。

今回はテストの総数が4つと少なく、またそれぞれの内容も簡単でしたが、テストの数が多かったり複雑なものが増えてきた場合ですと、失敗時のテスト時間の短縮になります。

おわりに

Pythonでpytestの-xオプションについての概要」について解説しました。

「テストが多すぎて時間かかるから、1つでも失敗してたらその時点で終了して欲しい」時に役に立ちそうです。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

https://ya6mablog.com/how-to-use-pytest-option/