文字の変換(CSVファイルをADOで扱う⑧)

CSVファイルをADOで扱う連載の8回目です。前回の記事はこちらになります。

hirocom777.hatenadiary.org

文字の変換

 前回は、SQLを指定してCSVファイルを確認できるツール(CSV_ReaderSQL)で読込と同時に計算してみました。これができると色々なことに応用できますよね。

f:id:HiroCom777:20210725124836j:plain

今回は文字データの変換です。文字データも読込と同時に変換できたりすると便利です。ツールは以下からダウンロードしてください。

05_SQLで選んでみよう.zip - Google ドライブ

名簿のデータを変換する

今回は、以下の名簿データの表記を変換してみようと思います。ファイル名は'NameList.csv'としましょう。Nameの所が何だか書き方がバラバラですね。

"ID","Name","Age"
"1","Tom","25"
"2","Bob","18"
"3","MARK","30"

この表のNameのデータ表記形式を整理していきたいと思います。

文字形式を変換する

まずは全角表記を半角にしたいと思います。今までと同じようにCSV_ReaderSQLで'NameList.csv'があるフォルダーを指定して、SQLコマンド欄に以下を入力して実行ボタンを押します。

  SELECT ID,STRCONV(Name,8) As Name,Age FROM [NameList.csv]

結果は・・・

ID Name Age
1 Tom 25
2 Bob 18
3 MARK 30

ちゃんと半角になってますね!!でもあともうちょっと。先頭は大文字、後は小文字という風に表記を統一したいです。今度はSQLコマンド欄を以下の様にして実行してみましょう。

  SELECT ID,STRCONV(Name,11) AS Name,Age FROM [NameList.csv]

結果は・・・

ID Name Age
1 Tom 25
2 Bob 18
3 Mark 30

これで完璧です。

STRCONVの使い方

この様にSTRCONVは文字列の変換が行えます。表記方法は以下の通りです。

  STRCONV(文字列式,変換方法) 

変換方法は整数値で表します。また、定数で指定する事もできます。以下の表をご確認ください。

定数 説明
vbUpperCase 1 文字列を大文字に変換します。
vbLowerCase 2 文字列を小文字に変換します。
vbProperCase 3 文字列内の各単語の先頭の文字を大文字に変換します。
vbWide 4 文字列内の半角文字(1バイト)を全角文字(2バイト)に変換します。
vbNarrow 8 文字列内の全角文字(2バイト)を半角文字(1バイト)に変換します。
vbKatakana 16 文字列内のひらがなをカタカナに変換します。
vbHiragana 32 文字列内のカタカナをひらがなに変換します。
vbUnicode 64 システムの既定のコードをUnicodeに変換します。
vbFromUnicode 128 Unicodeからシステムの既定のコードに変換します。

複数の処理を指定する場合は、組み合わせをする処理を足した値を指定します。今回の処理の場合、半角文字に変換したうえで先頭の文字のみ大文字としたのでvbNarrow + vbProperCase = 11 となります。当然ですが、相反する処理(vbWideとvbNarrow、vbKatakanaとvbHiraganaなど)は同時に指定できません。

ここまでの説明でお気づきの方もいらっしゃると思いますが、VBAのStrConv関数とほぼ動作が同じです。SQLで記述してしまえば読み込んだ後に処理をしなくて済むので便利ですね。

また、単純に大文字、小文字に変換するだけならばUCASE,LCASEを使った方が引数が少なくてシンプルです。表記方法は以下の通りです。 大文字にする場合は

  UCASE(文字列式) 

小文字にする場合は

  LCASE(文字列式) 

となります。こちらもVBAのUcase,Lcase関数と同じです。

次回も文字データ

 今回は、文字データの変換についてご紹介しました。前回の計算と合わせて使えば効果バツグンですよ!! 実はこれ以外にも文字データを扱う仕組みが色々あります。次回ご紹介しますので、お楽しみに!!

CSVファイルをADOで扱う連載記事はコチラからどうぞ

今までのおさらい(Gitを知ろう)

Gitについて学習してする連載の7回目です。前回の記事はこちらになります。 hirocom777.hatenadiary.org 今回は、今まで学んできた内容を一度おさらいしてみようと思います。

Gitはなぜ難しい(と、思われている)のか?

前回までご紹介した内容を繰り返し練習すると、ファイル管理の基本は可能なんだと思います。覚えてしまえばさほど難しくはないですよね。

f:id:HiroCom777:20210711150550j:plain

それではGitはなぜ難しい(と、思われている)のでしょうか?僕は以下の2つが原因なのだと考えています。

* 機能多すぎ

最初にお話したとおり、Gitを作ったのは神様みたいな人なので便利な機能がいっぱいついています。でも、やることは基本データの管理。なのでほとんどの機能は余り使うことはないと思うのです(神様および、めっちゃ頭いい人は別)。自分だけでファイルの管理をするだけならば、ここまでの連載でご紹介した内容だけおさえておけば、十分じゃないですか?

* いっぺんに色々説明しすぎ

そして、これらの機能について一度にたくさん説明している例が多いのです。Gitに関して説明しているWeb記事をみると、ほとんどがGitとGithHubを一緒に説明しています。今までご紹介したとおり、Gitだけでもデータの管理はできるんですよね。まずはGitから順序よく理解を深めればいいのにって思いました。

以上のことを感じて今回の連載をはじめました。そして、ここまで書いた今でも余り気持ちは変わっていないです。

どうしてこうなっているのでしょうか?それは、Git(とGitHub)を使うことで複数の人たちが効率良くプロジェクトを進めていくことができるというのが大きな利点だからなのだと思います。でも、ちょっと急ぎすぎじゃないですか?この連載では、もう少しゆっくり進んでいこうと思います。

以下に、ここまでで出てきた内容をまとめておこうと思います。

Gitを使ったファイル管理の段取り

Gitを使ったファイル管理の段取りを以下に示します。意外とシンプルでしょ?

  1. ファイルを管理するフォルダーを指定する
  2. フォルダーを右クリックしてGit Bash HereでGit Bashを開く
  3. git initでリポジトリを作成する
  4. フォルダー内にファイルを作成変更する
  5. git addで管理対象を登録する(ステージング)
  6. git commitで管理対象を記録する(コミット)
  7. 以降完成まで4~6を繰り返す。git statusを使って確認しながら作業を進めていくとよい

以前のコミットを確認する方法

以前のコミットを確認する方法です。確認用のブランチを作るのがオススメです。

注意:ブランチを切り替える前には必ずコミットしておきましょう

  1. git branch 確認用ブランチ名で確認用ブランチをつくる
  2. git checkout 確認用ブランチ名で確認用ブランチに切り替え
  3. git log --onelineで確認したいコミットIDを確認
  4. git reset --hard コミットIDで確認したいコミットに移動
  5. コミットの状態を確認(変更や修正はしないよう注意すること)
  6. git checkout 大元のブランチ名で大元のブランチに戻る
  7. git branch -d ブランチ名で確認用ブランチを削除

ブランチを使って開発を進める

開発用のブランチを作って大元に影響することなく開発を進める方法です。

注意:ブランチを切り替える前には必ずコミットしておきましょう

  1. git branch 開発用ブランチ名で開発用のブランチをつくる
  2. git checkout 開発用ブランチ名で開発用ブランチに切り替え
  3. 開発を進める
  4. 開発が完了したらコミットする
  5. git checkout 大元のブランチ名で大元のブランチに戻る
  6. git merge 開発用ブランチ名で開発用ブランチの内容を大元のブランチに統合する
  7. 必要であればgit branch -d 開発用ブランチ名で開発用ブランチを削除

今まで勉強したGitのコマンド

ここまで学んだGitのコマンドをまとめておきます。

コマンド 機能
git init リポジトリを作成する
git status ファイルの管理状態を確認、表示する
git add ファイル名 ファイルを管理対象として登録(ステージング)する
git commit 管理対象を記録(コミット)する
git log 変更履歴を確認する
git log --oneline 変更履歴を確認する(短縮版)
git show コミットID コミットIDで指定したコミットの内容を表示する
git diff コミットID_1 コミットID_2 コミットID_1とコミットID_2の差異を表示する
git reset --hard コミットID コミットIDで指定したコミットに移動する
git reset --hard HEAD~数値 数値で指定しただけ前のコミットに移動する
git reset --hard ORIG_HEAD git resetをなかったことにする
git branch ブランチ名 ブランチを作成する
git checkout ブランチ名 ブランチを切り替える
git merge ブランチ名 指定したブランチと統合する
git merge --abort git mergeをなかったことにする
git branch -d ブランチ名 ブランチを削除する

次回はリポジトリ

今回は、今まで学んできた内容のおさらいでした。こうしてまとめるとすっきりしませんか?次回はリポジトリについて解説してみようと思います。

Grove Beginner Kit For Arduinoの連載が本になりました

皆さんこんにちは。2020年の7月から12月まで、僕はGrove Beginner Kit For Arduinoというマイコンボードキットについてブログの連載をしていました。連載は以下からご覧になれます。

hirocom777.hatenadiary.org

そして今回、上の連載をもとに内容を見直して纏めた本を書きました。技術書典11にて2021年7月10日本日発売です。

techbookfest.org

本当にできるのかな・・・と半信半疑ながら作業を勧めていたのですが、ある日突然「作業はこれ終わりです」と言われました。本書くのってこんな感じでいいのでしょうか?ってのが実感です。まさか本当にこうなるとは思いませんでしたが、なんとか形になったようです。(まだ実感できていません。)

実際にやってきたことは?

では、本を作るにあたって実際にやったことはどんなことなんでしょうか?僕の場合は以下の手順を踏みました。

企画書を作る

まず企画書を書きます。本の骨組みですね。僕の場合は以下のような感じで書きました。実際にはもっと内容を書いているのですが、ここには概要だけを載せておきます。

# 企画書 3000円とパソコンだけで始められるマイコン入門

## ターゲット

電子工作に興味はあるが、ハードルが高いため二の足を踏んでいる人。
マイコンについて学習したいが、どこから手を付けていいかわからない人。
身の回りの電子機器がどのように動いているか興味のある人。
パソコンの操作、プログラミングがある程度理解できている人。

## 背景

# 構成
## はじめに

## 第1章 マイコンって何?
### 1.1 マイコンとArduino
### 1.2 これがGrove Beginner Kit For Arduino

## 第2章 プログラムしてみよう
### 2.1 思い通りにする準備
### 2.2 書きこんでみよう
### 2.3 少し複雑なスケッチ
### 2.4 アナログ入出力

## 第3章 マイコンに語ってもらう
### 3.1 音を出してみる
### 3.2 パソコンとつながる
### 3.3 文字を表示する

## 第4章 ガジェットを作ろう
### 4.1 キッチンタイマーを作る
### 4.2 骨組みを作ろう
### 4.3 使いやすくしよう
### 4.4 機能を追加してみよう

## おわりに

原稿を書く

企画が通ったら、それに沿ってずんずん原稿を書いていきます。僕の場合は先にご紹介したブログの連載記事をまとめる形で書いていきました。企画がしっかりまとまっていると本を書くとき楽ですし、内容もいい本になると思います。キリのいいところまで書いたら、原稿をみてもらいます。OKが出たら次の原稿に進みます。

PDFファイルにしてもらう

ひととおり完成したらPDFファイルに変換してもらいます。変換した形だと、違う視点から見ることができて修正点が見つかったりします。写真やスクショなども、感じがちょっと違うな・・・というところは撮りなおしました。

表紙(装丁)を依頼する

表紙はクラウドでコンペしてもらいました。便利な時代になりましたね。素敵な表紙でとても気に入っています。

f:id:HiroCom777:20210710184909j:plain

技術書典申し込み

技術書典の運営事務局に出典を申し込みます。

当然のことながら僕一人でこれら作業をできるわけなく、全体を通して(とくに原稿を書く以降)は、プランノーツ株式会社タカハシさんに多大なご指導とサポートをいただいております。ありがとうございました。

書き上げてみて思った

学んだことを纏めておくと、得られた成果をより有効的に活用できるようになります。そして。纏めること自体もさらなる学びになると思います。僕の場合、ブログで連載していたこと自体が本当によかったです。そしてさらに、本という形で纏められたことで更なる学びがありました。

このあとどうするか

さて、今回とてもいい経験だったので僕自身機会があれば、また本を書くことにチャレンジしてみたいと思っています。でもそれには、何か新しいコンテンツを用意しなければなりません。今回は最初に述べた通り約半年をかけて書いたブログの連載を元に書いたのですが、それに相当する、またはそれ以上のコンテンツを用意するのにはそれなりの時間と労力がかかるでしょう。

あと、本を書くって大変だけれどもすごい体験ができます。できれば他の人が本を書く際のお手伝いなどできたらいいな!!なんて思っています。

ノンプロ研の技術ライティング講座、オススメです。効率のいい学びに必要なアウトプットのためのライティング技術を学べます。

tonari-it.com

やり切れば、本を書く経験ができるかもしれません。お待ちしています!!

ブランチを統合する(Gitを知ろう)

Gitについて学習してする連載の6回目です。前回の記事はこちらになります。 hirocom777.hatenadiary.org

ブランチを統合する

前回は、ブランチで作業している領域を分岐してみました。ちょっとした確認をしたい時に便利ですよね。

f:id:HiroCom777:20210704165531j:plain

今回は、分岐した内容を修正して大元に反映させてみましょう。

お試しブランチで修正してみる

ブランチを使えば、できるかどうか判らないけれどちょっと試してみたい。そして、もし上手くいったら大元に反映したい。等ということができます。上手く行かなった場合には分岐を取り消して元に戻ってしまえば大元は無事と言う訳です。

それでは前回の状態から進めていきたいと思います。以下のような状態です。コミットを3回実行していて、ファイルは2つ(File_1.txt,File_2.txt)、ブランチによる分岐はありません。

新しくブランチ'branch-test'を作って、そちらに切り替えましょう。

この状態で、ファイル(File_3.txt)を追加してみます。ファイルの中は以下の様にします。

Good by!!

以下のような状態になりました。

f:id:HiroCom777:20210704170156j:plain

ブランチを切り替えるときの注意

さて、この状態で一度masterブランチに戻ってみましょう。masterブランチではファイルは2つでした。

f:id:HiroCom777:20210704170415j:plain

あれ?masterブランチでもファイルは3つになっています!!実を言うと、ファイルを変更、追加した後にコミットをしないで他のブランチに切り替えると、切り替えた先のブランチに変更、追加内容が移動してしまいます。このままでは危ないのでbranch-testに戻ってコミットを実行しましょう。記録内容は以下の様にしました。

Gitの使い方を学習します_04

ブランチをコミットしました
f:id:HiroCom777:20210704170803j:plain

この状態でブランチをmasterに切り替えると・・・今度はファイルが2つになっています。

f:id:HiroCom777:20210704170954j:plain

ブランチを切り替える前には、必ずコミットしている状態かどうかを確認しておきましょう。

マージしてみる

それでは分岐してファイルを追加したブランチbranch-testをmasterに統合(マージ)してみましょう。 masterに切り替えた状態で、以下を入力しましょう。

git merge ブランチ名

以下のような画面になります。

f:id:HiroCom777:20210704171629j:plain

ちゃんとマージできたようです。branch-testでコミットした内容も記録されています。

衝突したらどうする?

上の例ではファイルを追加しただけなのですが、ファイルを修正した場合でも処理は同様です。でも、masterとbranch-testで同じファイルに異なる変更してしまった場合しどうなるのでしょうか?試してみましょう。

まず、masterブランチに切り替わっていることを確認してFile_3.txtの内容を以下の様に書き換えます。

Good by!!
See you again!!

この内容をステージングしてコミットしましょう。記録内容は以下の様にしました。

Gitの使い方を学習します_05

masterのFile_3.txtを編集しました
f:id:HiroCom777:20210704172139j:plain

次にbranch-testブランチに切り替えて同様にFile_3.txtの内容を以下の様に書き換えます。

Good by!!
See you later!!

こちらもステージングしてコミットします。記録内容は以下の様にしました。

Gitの使い方を学習します_06

branch-testのFile_3.txtを編集しました
f:id:HiroCom777:20210704172531j:plain

今度はmasterをbranch-testにマージします。

f:id:HiroCom777:20210704173014j:plain

すると、あれ?なんかおかしい。これはコンフリクト(衝突)という状態です。masterとbranch-testでFile_3.txtの内容を変えてしまったのでこんなことが発生しているのです。File_3.txtをメモ帳などで開いてみると以下の様になっています。

Good by!!
<<<<<<< HEAD
See you later!!
=======
See you again!!
>>>>>>> master

2行目は'See you later!!'と'See you again!!'どっちが正しいの?と言う訳です。このままではまずいので、今回のマージはなかったことにしましょう。以下を入力すると、直前のマージが無かったことになります。

git merge --abort

さらに、branch-testのFile_3.txtの2行目'See you later!!'をなかったことにしたいと思います。'Gitの使い方を学習します_04'のコミットに戻ればいいですね。コミットIDで任意のコミットに移動する方法を以前ご紹介しました。今回もそれでいいのですが、ひとつ前のコミットに戻るということで以下を入力すればいいと思います。

git reset --hard HEAD~1

最後の数値を変更すると、指定した回数だけ前のコミットに戻れます。

f:id:HiroCom777:20210704173336j:plain

実行してFile_3.txtを確認すると

Good by!!

となっています。この状態でもう一度masterとマージしてみましょう。

f:id:HiroCom777:20210704175451j:plain

今度は上手くいったようです。branch-testのFile_3.txtは以下の様になりました。

Good by!!
See you again!!

次回はおさらい

いかがでしたか?ここまでご紹介した内容を繰り返し練習すると、Gitの操作方法が理解できるようになると思います。次回は今までのおさらいです。お楽しみに!!

hirocom777.hatenadiary.org

ブランチを使う(Gitを知ろう)

Gitについて学習してする連載の5回目です。前回の記事はこちらになります。 hirocom777.hatenadiary.org

ブランチを使う

前回は、変更履歴を利用する方法をご紹介しました。これだけのことができれば、簡単なドキュメントやソフトウェアの開発には利用できると思います。

f:id:HiroCom777:20210628220721j:plain

でも大概の場合、開発とは一筋縄では行かないものです。そんな時のためにGitには逃げ道が用意されているんですよ。今回は、この逃げ道であるブランチ(分岐)について取り組んで見ようと思います。

管理を分割する

ドキュメントやソフトウェアの開発で、順調に進んでいる間はどんどん改版していけば問題ないです。でも大概の場合、開発途中で『ひょっとしたら、こうした方がいいのでは?』とか、『別の方法も試してみたいんだけど?』とか、色々疑問がわいてきます。色々やってみたいのだけれども、現在の状態に影響を与えたくはない・・・

そんな時のために、Gitではブランチという機能があります。今まで紹介したGitの使用例では、1つの開発を一直線に記録していきました。できるのは後戻りだけです。ブランチを使うと、開発の流れを分岐して記録できます。分岐の大本はそのままにしておいて、分岐した側で色々な作業が可能です。1つのリポジトリの中で複数の作業が可能になるわけです。

ブランチを使ってみる

それでは前回の状態(コミットを3回実行した状態)から進めていきたいと思います。まず、新しくブランチを作りましょう。ブランチの名前は、'branch-test'としたいと思います。

Git branch ブランチ名

で、新たにブランチを作ることができます。これで'branch-test'というブランチができあがりました。続いて以下を入力してみてください。

Git branch

以下のような画面になったと思います。

f:id:HiroCom777:20210628220934j:plain

Git branchで現在のリポジトリ内のブランチ一覧が確認できます。現在、'branch-test'と'master'の2つのブランチがあることがわかります。'master'は最初に'Git init'でリポジトリを作成してコミットした際にできたブランチです。今まではmasterブランチ上で作業していたんですね。それでは、branch-testブランチに切り替えてみましょう。

Git checkout ブランチ名

でブランチを切り替えることができます。続いて、Git branchでブランチ一覧を確認してみましょう。

f:id:HiroCom777:20210628220956j:plain

先ほどはmasterの先頭に'*'が付いていましたが、branch-testの先頭に表示されるようになりました。ディレクトリ表示の右側にある表記(master)から(branch-test)に変わりました。ここを確認することで現在どのブランチにいるかがわかります。リポジトリの内容とファイルも確認してみましょう。

f:id:HiroCom777:20210628221111j:plain

ちゃんとコピーされているみたいです。

切り替えたブランチで作業してみる

それでは切り替えたブランチで作業してみましょう。手始めに、前回と同じように最初のコミットに戻って見たいと思います。

Git reset --hard コミットID

で、コミットIDで指定したコミットに戻るんでしたね。早速入力してみましょう。

f:id:HiroCom777:20210628221157j:plain

git logで確認すると、ちゃんと最初のコミットに戻っているみたいです。ファイルも1つだけになっています。こちらもファイルが1つになっています。ファイルの内容も最初のコミットの状態に戻りました。対象のフォルダーをWindowsで開いてみるとファイルが1つになっていることがわかります。

それではこの状態でmasterブランチに戻ってみましょう。Git checkout masterで戻ってみます。

f:id:HiroCom777:20210628221420j:plain

こちらは元のままです。Windowsでフォルダーを確認してもファイルが2つになっていて内容もそのままです。branch-testブランチで実施した作業はmasterブランチには影響していないことが判りました。

過去のコミットを確認したいとき

前回もお話した通り、できるからと言って何かにつけてコミットを戻したりしているとトラブルの原因になりかねません。でも、過去のコミットを確認したいときもある・・・そんな時には今回の様にブランチを作成して、そのブランチ上で確認するといいと思います。また、現在どのブランチ上にいるかを常に意識して作業しましょう。

今回作ったブランチは、役目を終えたので削除しておきましょう。

Git branch -d ブランチ名

でブランチを削除できます。以下の様になると思います。

f:id:HiroCom777:20210628221449j:plain

ブランチはmasterだけになりました。

次回はマージ

いかがでしたでしょうか?ブランチはとても便利ですね。次回は、ブランチで作業した内容をおおもとに反映させて見たいと思います。お楽しみに!! hirocom777.hatenadiary.org

変更履歴を利用する(Gitを知ろう)

Gitについて学習してする連載の4回目です。前回の記事はこちらになります。

hirocom777.hatenadiary.org

変更履歴を利用する

前回は、変更履歴を確認する方法をご紹介しました。

f:id:HiroCom777:20210627174622j:plain

でも、この変更履歴・・・確認できるだけじゃ意味がないですよね?積極的に利用する方法を模索しましょう。

コミットの詳細を確認する

まず、任意のコミットの内容を確認してみましょう。任意のコミットを確認するには、確認したいコミットを指定しなければなりません。コミットの指定はコミットIDで行います。コミットIDとはコミットを一意に識別するための値です。コミットしたデータの内容だけではなく、コミットした人の情報、前のコミットIDなどの情報をもとに算出されます。コミットIDは、git logで確認できます。

f:id:HiroCom777:20210627174516j:plain

この40の英数文字がコミットIDです。この文字列で任意のコミットを指定できるのですが、ちょっと長すぎて使い勝手がよくありません。そこで、実はコミットIDの先頭の7文字だけでもある程度コミットを指定できるようになっています。コミットIDの先頭7文字(短縮版コミットID)は、git log --onelineで取得できます。各コミットの先頭に表示されているのが短縮版コミットIDです。

f:id:HiroCom777:20210626174052j:plain

それでは、以下の様に入力してみてください。

Git  show (短縮版)コミットID

コミットが極端に多くなると、短縮版のコミットIDではコミットを指定できなくなることがあるそうですが、一般的には短縮版で十分機能すると思います。ここでは2回目のコミットについて確認してみます。僕の場合コミットIDの部分はを'a6711fd'と指定しました。皆さんの環境では別の値になります。結果を確認してみましょう。画面は以下の様になりました。

f:id:HiroCom777:20210627182713j:plain

上から、コミットID、コミットした人と日時の情報、コミットする際に入力した情報、そして前回のコミットとの違いが表示されます。File_1.txtの最終行に追加したテキスト(How are you?)を確認できますね。

コミットの内容を比べる

コミットIDでコミットを指定することによって2つのコミット内容の比較ができます。最初と3回目(最後)のコミットを比べてみましょう。 以下を入力します。コミットIDは短縮版でOKです。

Git diff コミットID_1 コミットID_2 

結果は以下の様になりました。

f:id:HiroCom777:20210627182833j:plain

'File_1.txt'には行の追加がある旨が表示されています。また、最初のコミットには'File_2.txt'自体がないこともわかりますね。

任意のコミットに戻る

現在のコミットが間違っていると気が付いたとき、過去の任意のコミットまで戻ることができると便利です。お次は任意のコミットの時点まで戻る方法をご紹介します。前回の状態から最初のコミットまで戻ってみましょう。前回までで、3回のコミットを実行しました。その都度ファイルの中身を変更したり、ファイルを追加したりしました。その流れは以下の様に確認できます。

f:id:HiroCom777:20210627182849j:plain

現在2つのファイルと3つのコミットが存在しています。新しくコミットするべきものはありません。この状態から、一番最初のコミットに戻ってみようと思います。この場合もコミットの指定はコミットIDを使用します。

戻る前にGit Bashで開いているフォルダーの内容をWindowsで開いて確認してください。'File_1.txt'、'File_2.txt'の2つのファイルが確認できると思います。

それでは、Git Bashに戻って最初のコミットに戻ってみましょう。以下を入力します。こちらもコミットIDは短縮版でOKです。

Git  reset --hard  コミットID

git logで状態を確認してみると、最初のコミットの状態に戻っていることがわかります。

f:id:HiroCom777:20210627182909j:plain

再びWindowsで開いているフォルダーの内容を確認してみましょう。ファイルは'File_1.txt'だけになっています。メモ帳などで、その内容を確認してみると・・・

Hello!!

と、なっているはずです。最初のコミットに戻ることができました。

元に戻した行為の取り消し

元に戻ってはみたのだけれど、やっぱり戻らなくてもいいや!!ってなった時は以下の入力で変更を取り消すことができます。

git reset --hard ORIG_HEAD

git logで確認すると、コミットを3回実行した状態に戻っています。ファイルの内容、数も元に戻っていますね。

f:id:HiroCom777:20210627182925j:plain

これで、いつでも任意の状態に戻ることができます。でも、何かにつけてコミットを戻したりしているとトラブルの原因になりかねません。基本的にはコミットを重ねて仕事を進めていく方向で運用しましょう。

次回はブランチ

以上、今回は変更履歴を利用する方法についてご紹介しました。次回はブランチについて説明しようと思います。お楽しみに!!

hirocom777.hatenadiary.org

どうやって管理しているの?(Gitを知ろう)

Gitについて学習してする連載の3回目です。前回の記事はこちらになります。

hirocom777.hatenadiary.org

ファイル管理をしてみよう

前回は、Gitによる簡単なファイル管理の例をご紹介しました。

f:id:HiroCom777:20210620170840j:plain

ですが、記録された変更内容はどのように管理されているのでしょうか?知りたいですよね。今回は、そこを追求し行きたいと思います。

変更履歴を確認する

変更内容と言っても、今回新しくファイル、フォルダーを作ったばっかりなので具体的な変更はまだなのです。とりあえず変更履歴を確認する方法をご紹介します。前回同様Localフォルダーを選択して右クリック⇒Git Bash Hereを選択してください。この画面で以下を入力してEnterしてみましょう。

git log

画面が以下の様になったと思います。git logは変更(コミット)の履歴を表示するコマンドです。

f:id:HiroCom777:20210626173034j:plain

一番上、commitの後に書かれている意味不明の数字の羅列は今回のコミットで対象となったファイル、フォルダーのチェックサムです。俗称でコミットID等と呼ばれているようです。続くかっこの中の'HEAD'は現在の作業場所を指します。矢印がさしている先の'master'は現在作業しているブランチです。(ブランチについては別途ご説明します) その下に続くのは、作業者の情報とコミットの日時、そして前回テキストエディターで入力した記録のタイトルと詳細です。

ファイルを変更して履歴を見てみる

それではLocalフォルダー内のFile_1.txtを編集してその内容を記録してみましょう。ファイルの内容は以下の様に編集しました。

Hello!!
How are you?

前回と同じように管理対象を登録(git add File_1.txt)して記録(git commit)します。記録のタイトルと詳細は、以下の様に入力しました。

Gitの使い方を学習します_02

二番目のコミットです。How are you?を追加しました。

結果は以下のような画面になりますね。

f:id:HiroCom777:20210626173225j:plain

それでは再度、git logで変更履歴を確認してみましょう。

f:id:HiroCom777:20210626173310j:plain

あ、今度は2つ出てきた。ちゃんと記録は取られているようです。

ファイルを追加してみる

それでは、ファイルを追加した場合はどうでしょうか?やってみましょう!!Localフォルダー内のFile_2.txtを追加します。内容は以下の様にしましょう。

Let's go to lunch together next time.

File_1.txtは以下の様にします。

Hello!!
How are you?
Please check File_2.txt.

今度は管理対象のファイルが2つ(File_1.txt,File_2.txt)になりました。複数のファイルを管理対象として登録する場合、スペースで挟んで記述できます。以下の様になります。

git add File_1.txt File_2.txt

でも、フォルダー内のすべてのファイルを指定する場合はファイル名の代わりに'.'を使うことができます。

git add .

それでは記録(git commit)してみましよう。記録のタイトルと詳細は、以下の様に入力しました。

Gitの使い方を学習します_03

三番目のコミットです。ファイル追加しました。

画面は以下の様になりました。

f:id:HiroCom777:20210626173644j:plain

git logで変更履歴を確認してみましょう。記録が3つになっています。

f:id:HiroCom777:20210626173725j:plain

でも、何だか表示がごちゃごちゃしてきました。以下を入力すると画面表示がクリアされます。

clear

今度は以下の様に入力してみてください。

git log -2

表示される履歴が直近の2つのコミットになったと思います。この方法で表示する履歴の数を指定することができるのです。もう一度画面表示をクリアして、今度は以下の様に入力してみてください。

git log --oneline

以下のような画面になりました。

f:id:HiroCom777:20210626174052j:plain

ぐっとシンプルになりました。各コミットの先頭にある7文字は先に紹介したコミットIDの先頭7文字です。

入力が面倒になってきたら

ここまで色々なコマンドを入力してきましたが、似たような内容を何度もタイプするのが面倒になってきたと思います。そんな時はカーソルキーの上矢印で過去に入力した内容が順に現れますのでご活用ください。一度表示した状態で下矢印を押すと逆に表示されます。

変更履歴を利用する

今回はgit logを中心に、変更履歴を確認する方法をご紹介しました。でも、確認できても過去の状態に戻ったりファイルを確認したりできなければ意味ありませんよね。次回は記録したコミットを使用する方法について考えてみようと思います。お楽しみに!!

hirocom777.hatenadiary.org