【電気・電子】ジャイロセンサーモニターのソースコード公開に向けて、Gitを使えるようになりました

電気・電子

　ずいぶん前にバージョン管理ツールTortoiseSVN（トータスSVN）を導入したことをブログに投稿しました。

【バックヤード】パソコンにバージョン管理ツールTortoiseSVN（トータスSVN）を導入しました
今回は、プログラミングを2台のパソコンで同じプログラム（プロジェクト）を編集できるようにするために、バージョン管理システムを導入しました。バージョン管理には無料で使用できるVisualSVN ServerとTortoiseSVNを採用しました。大げさそうに見えますが、簡単にインストールや設定ができました。使い方もチェックアウトとコミットが理解できれば使えることがわかりましたでの紹介します。
miyabee-craft.com
2024.02.11

　投稿からもう1年以上経っていました。時間が経つのが早いですね。こんな話を聞いたことがあります。”1年の長さの感じ方は、1年を年齢で割った長さだよ”。もうすぐ61歳になるので、感じ方は1÷61=0.016年。早すぎ！でもそれぐらい早いかも…ww
　当時のブログにもGitとSVNの違いやGitとGitHubの違いについて書いていました。GitHubの利点に『GitHubでソフトウェアを作成した際にプロジェクトを公開したり、ソフトウェアを公開することができます。』とありました。ようやくその時になりました。先回の投稿で公開したジャイロセンサーモニターのソースコードをGitHubを使って公開したいと思います。

【電気・電子】OpenGLによるジャイロセンサーモニターをバージョンアップしました
「やっぱり、OpenGL上でジャイロセンサーMPU6050を使って3D紙ヒコーキを飛ばしてみた」の続編です。今回は、ジャイロセンサーモニターのバージョンアップ内容について紹介します。紹介したジャイロセンサーモニターもダウンロードできますので、興味のある方はご利用ください。
miyabee-craft.com
2025.04.14

　ソースコードの公開だけならGitHubサービスだけでもできますが、公開したものに対して修正や改良してバグを作りこんでしまうことはできるだけ回避したいので、ローカル（自分のパソコン）で変更や確認をしてから公開した方がよいと思います。そこで、Gitも使えるようにしておきたいと思います。

Gitが使えるようになるまで

私自身がGitを理解して使えるようになった手順を紹介します。

１. Gitのインストール

　最初にGitを使えるようGitをインストールします。Windows用のGitインストーラからダウンロードします。

　以下のような画面のインストーラサイトが開きます。[Download]をクリックすると「Git-2.49.0-64-bit.exe」（時期によってファイル名が変わります）がダウンロードされますので、ダブルクリックして実行します。

インストーラ画面が開き、ライセンス事項を確認して、[Next]ボタンをクリックします。

インストール先フォルダを指定する画面です。そのまま[Next]ボタンをクリックします。

インストールするコンポーネントを選択します。そのまま[Next]ボタンをクリックします。

スタートメニューのフォルダを指定します。そのまま[Next]ボタンをクリックします。

Gitで使用するデフォルトのエディターツールを選択します。ここでは「Use Visual Studio Code as Git’s default editor」を選択します。お好きなものを選んでください。

エディターを選択したら、[Next]ボタンをクリックします。

新規作成したブランチのデフォルトブランチ名を決めます。最近は「main」が主流のようですので、[Override the default brach name for new repositories]にチェックして[Next]ボタンをクリックします。

私がインストールしたときは「master」でした。後でデフォルトのブランチ名を「master」から「main」に変更したい場合は、git bashで以下のコマンドを実行すればできます。

git config --global init.defaultBranch main

環境変数PATHをWindows環境で使う場合は、[Git from the command line and also from 3rd-party software]を選択して、[Next]ボタンをクリックします。

SSH実行モジュールを選択します。既に何らOpenSSHを使っていなければ[Use bundled OpenSSH]を選択して[Next]ボタンをクリックします。

SSHとは、Secure Shell の略で、ネットワーク経由で別のコンピュータやネットワーク機器を安全に操作するために使われるプロトコルです。また、OpenSSHはSSHプロトコルを使ったソフトウェアでリモートログインやファイル転送などを行えます。

Git が HTTPS接続に使用するSSLライブラリを指定します。[Use the OpenSSL library]をチェックして、[Next]ボタンをクリックします。

Gitにおいてテキストファイルの行末をどのように扱うべきかを選択します。Windowsで使用するので[Checkout Windows-style, commit Unix-style line endings]をチェックして、[Next]ボタンをクリックします。

Git Bashで使いたいターミナルを選択します。[Use MinTTY (the default terminal of MSYS2)]をチェックして、[Next]ボタンをクリックします。

git pullのデフォルトのふるまいをどうするかを選択します。[Fast-forward or merge]をチェックして、[Next]ボタンをクリックします。

どの資格情報ヘルプーを構成するかを選択します。Gitがリモートリポジトリとの通信中に要求される資格情報を処理するためのツールです。主に、GitのHTTPS認証などで、パスワードやトークンなどの資格情報を安全に保管・管理するために使用されます。[Git Credential Manager]をチェックして、[Next]ボタンをクリックします。

拡張オプションを選択します。
　[file system caching]オプションは、Git がファイルシステムのキャッシュを利用するかどうかを制御する設定です。この機能を有効にすることで、Git の操作（特に git status や git diff など）の応答速度を向上させることができます。
　[symbolic links]オプションは、Gitリポジトリ内にシンボリックリンクを追跡するかどうかを制御するための設定です。追跡することで、ソースコードの構造を保持し、バージョン管理を容易に行えます。ただし、追跡によっては、Gitの動作速度に影響を与える可能性があります。
　[Eanble file system caching]と[Eanble symbolic links]をチェックして、[Install]ボタンをクリックします。

インストールが始まります。

インストールが完了した画面です。[Finish]ボタンをクリックします。

WindowsスタートにGit Bash、Git GUI、Git CMDがインストールされていることを確認します。

2. Gitの初期設定

　Gitの初期設定を行います。初期設定では、ユーザー名とメールアドレスを登録します。

　Windowsスタートの検索に「git bash」と入力して、スタート画面に表示される[Git Bash]をクリックして実行します。
Git Bashのターミナル画面が開きます。

「＄」がプロンプトのマークで、コマンドを入力するところです。その上にヘッダーが表示されています。<ユーザー名>＠<ホスト名>が表示されます。

[MINGW64] は、Windows上でGitをコマンドラインで操作するためのターミナルを意味します。Git for Windowsをインストールすると、MINGW64 環境がインストールされ、Git Bash を利用できるようになります。

「～」は、Git Bashのルートディレクトリを示します。具体的には、C:\Users\<ユーザー名>のディレクトリにいます。

画面のユーザー名をマスクするのが手間なので、以下のコマンドを実行して、一時的にヘッダーを表示しないようにしましたのでご了承ください。

export PS1='\w$ '

　Gitの初期設定を行います。初期設定では、ユーザー名とEmailアドレスを以下のコマンドで登録します。
・ユーザー名の登録

git config --global user.name <ユーザー名>

・Emailアドレスの登録

git config --global user.email <メールアドレス>

実行結果です。ユーザー名はブログの名称にしてみました。

登録した内容は、以下のコマンドで確認できます。

git config --list

実行結果です。赤枠内のユーザー名とEmailアドレスが登録されていることがわかります。

また、赤枠より上部の内容はインストール時に選択した内容が設定されています。後からでも、この内容を変更すれば、構成を変更できることがわかります。

3. リポジトリの作成

　リポジトリとはバージョン管理システムにおいて、プロジェクトやコードの変更履歴やファイルを保存・管理するデータベースのような場所です。

ローカルリポジトリ: 開発者の個々のコンピュータ上に存在し、プロジェクトの変更履歴を保存します。

リモートリポジトリ: プロジェクト全体の中央データベースで、通常はクラウド上にあります（GitHubやBitbucketなど）。

早速、リポジトリを作成します。Git Bashというコマンドライン環境で作業を行うため、以下のようなコマンドを打ち込んで行います。mkdir（メイク ディレクトリという意味）はエクスプローラーでいうと[フォルダの新規作成]のことです。cd（チェンジ ディレクトリの意味）はエクスプローラーでは、フォルダツリーでフォルダーを移動することと同じです。例で説明すると、1行目で「github」ディレクトリ（フォルダ）を作成して、2行目で「github」ディレクトリ（フォルダ）に移動しています。

mkdir <ディレクトリ名 (例：github)>
cd <ディレクトリ名 (例：github)>
mkdir <リポジトリ名 (例：sample)＞
cd <リポジトリ名 (例：sample)>

実行結果です。

　ディレクトリとフォルダは、同じものです。git bashやコマンドプロンプトなどのようにコマンドラインで操作する場合はディレクトリと呼びます。WindowsのエクスプローラのようなGUIアプリ上ではフォルダと呼びます。以後の説明では、コマンドラインではディレクトリ、GUIアプリではフォルダと呼ぶようにします。

　3行目以降では<リポジトリ名>という言葉を使っています。これは、物理的にはディレクトリと同じですが、意味付けとして、このディレクトリをリポジトリとして使いますよ、という意味で使っています。

　リポジトリ名として作成したディレクトリを初期化して、名実ともにリポジトリにします。

git init

実行結果です。

「C:/Users/<ユーザー名>/github/sample/.git/」に空のGitリポジトリが作成されました。

　Gitリポジトリの正体は、「.git」というディレクトリです。このディレクトリ配下に変更履歴や状態が保管されます。したがって、「.git」ディレクトリを削除すれば、ただのディレクトリになります。

4. インデックス（ステージングエリア）に追加

　インデックスの役割として、ディレクトリ内に多数のファイルがあり、複数のファイルが編集や変更されていた場合、編集した一部のファイルだけリポジトリに登録したい場合があります。そのようなときに登録したいファイルのみをインデックスに追加します。これにより他の編集や変更ファイルと区別することができ、登録対象を整理することができます。

　以下のコードを作成してindex.htmlというファイル名で「sample」ディレクトリに保存します。このindex.htmlをリポジトリに登録してみます。

<!DOCTYPE html>
<html lang="ja">
<body>
  <h1>Hello World</h1>
</body>
</html>

　まず、以下のコマンドでリポジトリに登録するファイルをインデックスというステージングエリアに追加します。仮登録する感じです。

git add <ファイル名>

実行結果です。

5. リポジトリにコミット

　コミットとは、バージョン管理システムで行われる重要なアクションの一つで、変更内容をリポジトリに記録する操作のことです。

以下のコマンドでインデックスに追加したファイルをコミットします。

git commit -m "作業内容の説明"

　「-m “作業内容の説明”」は、コミットした際のメッセージを記録するためのオプションです。

実行結果です。

1行目：git commit -m “[Add] new file: index.html” は、インデックスに追加した「index.html」をコミットし、コミットメッセージとして「[Add] new file: index.html」を指定しています。

2行目：[master (root-commit) a493688] [Add] new file: index.html は、master: これは現在のブランチ名で、root-commit は「このコミットが最初のコミットである」ことを表しています。a493688 はこのコミットの 短縮されたハッシュID（変更を一意に表すID）です。[Add] new file: index.html は、コミットメッセージです。

3行目：1 file changed, 6 insertions(+) は、1ファイルが変更（追加）され、6行の新しいコードが追加されたことを表しています。

4行目：create mode 100644 index.html では、create mode はファイルが新しく作られ、100644 はファイルのパーミッション（読み書きできる通常ファイル）を表しています。

6. 現在の状態を確認

　コマンドラインで実行していると、今どういう状態かがわからないです。そこで次のコマンドを実行することで、状態を確認することができます。

git status

例えば、インデックスに「index.html」を追加した（上記 4.を実行）後の状態は以下のようになります。

「On branch master No commits yet」は、作業しているブランチは「master」であり、まだ一度もコミットされていないこと示しています。
「Changes to be committed: new file: index.html」は、次にコミットされる予定の変更は、新しく追加されたファイルの「index.html」であることを示しています。
「（use “git rm –cached <file>…” to unstage）」は、カッコは補足を表し、もしステージから取り消したい（コミットには含めたくない）なら、git rm –cached index.htmlを使ってね、を示しています。

　例えば、コミットした（上記 5.を実行）後の状態は以下のようになります。

1行目：On brach master は、作業しているブランチは「master」であることを示しています。
2行目：nothing to commit, working tree clean は、現在、ステージされている変更は何もなく、作業ツリー（＝ローカルのファイル）にも変更がないことを示しています。

7. ブランチを作成して切り替える

ブランチを作成（1行目）して、ブランチを切り替える（2行目）コマンドは以下の通りです。

git branch <ブランチ名>
git switch <ブランチ名> または、git checkout <ブランチ名>

従来はブランチを切り替えるコマンドはgit checkout <ブランチ名>を使っていましたが、最近は意味がわかりやすいgit switch <ブランチ名>を使うことが推奨されています。

実行結果です。ここでは、「develop」というブランチ名を作成します。作成後にgit branchコマンドを実行すると、「*」がついているmasterブランチが現在の作業ブランチであることがわかります。

次に、ブランチdevelopにブランチを切り替えました。git branchコマンドでブランチを確認すると、developに切り替わっていることがわかります。

ここでブランチを切り替えると何が変わるの？という疑問がわきます。

何が変わるかを見ていきたいと思います。

まず、現在は、ブランチdevelopで作業しています。sampleディレクトリにあるindex.htmlの朱書き部分を追加して保存します。

<!DOCTYPE html>
<html lang="ja">
  <style>
    h1 {
      color: #00ff40;
      font-size: 3rem;
    }
  </style>
<body>
  <h1>Hello World</h1>
</body>
</html>

以下のコマンドでこの変更をインデックスに追加します。

git add index.html

続けて、インデックスに追加した内容をコミットします。

git commit -m "[Add code] style"

実行結果です。ブランチdevelopにコミットメッセージ「[Add code] style」でコミットされ、その内容は１つのファイルが変更され、6行挿入された、という結果です。

sampleディレクトリにあるindex.htmlファイルをVisual Studio Code（好みのエディター）で開くと以下の通りで、変更されたとおりに表示されています。

では、ここで以下のコマンドでブランチをdevelop から master に切り替えて、現在のブランチを確認します。

git swtich master
git branch

実行結果です。ブランチはmasterに切り替わっています。

もう一度、sample ディレクトリにある index.html をVisual Studio Code（好みのエディター）で開いてみると、追加したはずの6行がなくなっています。

ブランチをmasterに切り替えたことで、sample ディレクトリは ブランチ masterの状態に置き換えられたことを意味します。この状態は「.git」ディレクトリ内に保管されているブランチ状態や履歴情報から復元されています。

もう一度、ブランチを develop に切り替えて、index.html ファイルをVisual Studio Code（好みのエディター）で開いてみてください。6行追加された状態に戻っていると思います。

8. 差分を確認する

　今、ブランチはmaster と develop の2つが存在します。編集とコミットを繰り返していくとブランチ間の差異がわからなくなってしまうことがあります。そんなときは以下のコマンドでブランチ間の差分を確認することができます。

git diff <ブランチ名１> <ブランチ名２>

実行結果です。ブランチ master と develop との差分を確認しました。

git diff master develop : ブランチ master と develop との差分を表示するコマンドです。コマンドの実行結果を1行ずつ見ていきます。

git diffの実行結果説明
diff –git a/index.html b/index.html比較しているファイルは index.html です。a/ は master のバージョン、b/ は develop のバージョンです。
index b61c503..c1d1c9e 100644index はファイルの変更前後の状態を表しています。b61c503 は master 側の index.html のバージョンID（ハッシュ値）。c1d1c9e は develop 側のバージョンID。
— a/index.html変更前（master）の index.html
+++ b/index.html変更後（develop）の index.html
@@ -1,5 +1,11 @@変更が起きた場所を示すマークです。-1,5 は「master側は1行目から5行分」+1,11 は「develop側は1行目から11行分」
+ <style>
+ h1 {
+ color: #00ff40;
+ font-size: 3rem;
+ }
+ </style>		具体的な変更内容です。
この + がついてる行は、新しく追加された行です。

git diffはブランチ間の差異の他にいろんな引数の種類があります。下表に簡単にまとめてみました。

　　　　　　コマンド例　　　　　　　　　　　比較対象説明
git diffワーキングツリー vs インデックスステージ前の変更を見る
git diff –staged（または–cached）インデックス vs HEAD「git add したけど git commit してない変更」を確認
git diff master developmasterブランチ vs developブランチ2つのブランチ間の差分を見る
git diff b61c503 c1d1c9eコミットID vs コミットID2つの特定コミット間の差分を見る
git diff masterワーキングツリー vs masterブランチ今の作業内容とmasterの違いを見る
git diff master develop — index.htmlmasterブランチ vs developブランチ（ファイル指定）2ブランチ間で特定ファイル(例：index.html)の差分を見る

9. 変更履歴を確認する

　プロジェクトが成長していくと、いつどういったソースコードを追加したとか、このバグ（不具合）はいつ作り込んだとかを確認することがあります。こんなときは以下のコマンドを使い、変更履歴を確認することができます。

git log

git logを実行するだけで、現在のブランチのコミット履歴を最新のコミットから古いコミットの順番（降順）で表示されます。
実行結果です。現在のブランチは develop で、その時の履歴が降順で表示されていることがわかります。

ちなみに、履歴を昇順で表示したい場合は、以下のコマンドを実行します。確認してみてください。

git log --reverse

さて、git logコマンドでよく使われるオプションを以下にまとめてみました。これらのオプションは組み合わせて使うことができます。

オプション説明例
--oneline各コミットを1行で表示（短いハッシュとメッセージ）git log --oneline
--graphブランチの分岐をASCIIアートで表示git log --graph
--allすべてのブランチの履歴を表示git log --all
--author="名前"特定の作者のコミットだけを表示git log --author="Tanaka"
--since="日付"指定した日付以降のコミットを表示git log --since="2025-04-01"
--until="日付"指定した日付以前のコミットを表示git log --until="2025-04-15"
--statファイルごとの変更行数を表示git log --stat
-p各コミットの差分（パッチ）も表示git log -p
--pretty=format:"..."出力フォーマットをカスタマイズgit log --pretty=format:"%h %an %s"
-n <数> または --max-count=<数>表示するコミット数を制限git log -n 5

10. ブランチをマージする

　git merge は、複数のブランチで分かれていた変更を1つにまとめるコマンドです。Gitを使ってチーム開発や機能ごとの作業をするとき、必ず使う重要な操作です。それぞれのブランチで作成したソースコードをmasterブランチにマージして完成させます。

git switch master
git merge <ブランチ名>

これは、masterブランチに切り替えて、現在のブランチ（master）に指定した<ブランチ名>の変更を取り込む操作です。

　masterブランチとdevelopブランチの差異は以下の通りです。developのindex.htmlに<style>タグの6行が追加されています。

　以下のコマンドを実行して、masterブランチにdevelopブランチの変更を取り込みます。

git switch master
git merge develop

実行結果です。結果を1行ずつ見ていきます。

git merge develop ：現在ブランチ（master）にブランチdevelopの変更を取り込みを実行します。
Updatting a493688..e4a3831 ：現在のブランチの最新コミットIDがa493688で、developブランチの最新コミットIDがe4a3831 であることを示しています。
Fast-forward ：この間の差分を「Fast-forward（巻き戻しなし）」でそのままマージできることを示しています。
index.html | 6 ++++++ ：index.html というファイルに6行追加されたことを示します。
1 file cheanged, 6 insetions(+) ：1ファイルが変更され、6行挿入されたことを示します。

　今回のマージは、masterブランチが何も変更されていないため、単純にdevelop側の変更を取り込むだけですみました。

ブランチ間に競合があった場合

　もし、masterブランチ側も同じ個所で変更されていた場合、今回のように機械的にマージすることができません。以下のようなマージ失敗の結果になります。結果を1行ずつ見ていきます。

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Auto-merging index.html ：index.htmlファイルを自動マージしますという意味です。
CONFLICT(content): Merge conflict in index.html ：index.htmlファイルにマージの競合がありますという意味です。
Automatic merge failed; fix conflicts and then commit the result. ：自動マージに失敗しました。競合を修正して結果をコミットしてください、と示しています。
マージが失敗した場合の対処方法は、手動で双方の変更を編集して、編集が終わったら以下のコマンドを実行します。

git add index.html
git commit -m "コミットメッセージ"（またはgit merge --continue）

複数ファイルのマージに競合があった場合

git merge はブランチ間のマージコマンドです。したがって、ブランチに複数のファイルがあり、複数のファイルに変更があった場合もまとめてマージ処理が行われます。

例えば、複数のファイルのうち1ファイルが競合している場合に git merge を実行するとどうなるでしょう。
結論から言うと競合のないファイルはマージされて、競合のあるファイルはマージに失敗します。その結果、マージ処理はマージ中（未完了状態）になります。

例えば、以下のようなマージ処理した結果が表示されたとします。

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Auto-merging app.js
Merge made by the 'recursive' strategy.

この結果の意味は、index.htmlファイルで競合が発生し、app.jsファイルはマージが完了したということです。

マージ中の対処方法には２つあります。
１つは、手動で変更を編集して、編集が終わったら以下のコマンドを実行します。

git add index.html
git commit -m "コミットメッセージ"（またはgit merge --continue）

もう１つは、マージをキャンセルしたい場合は、以下のコマンドを実行します。

git merge --abort

でマージ前の状態に戻せます。

11. 過去の状態に戻す

　編集を繰り返し、途中でアルゴリズムの変更や大掛かりな変更をしてしまって行き詰ってしまうことがあります。そんなときは、以下のコマンドで過去の状態に戻すことができます。そんなときは、以下のコマンドで過去の状態に戻すことができます。

git checkout <コミットID>

上記の10.でmasterブランチにマージしました。これを例にマージ前の状態に戻してみます。

まず、以下のコマンドでコミットIDを確認します。

git log --oneline

実行結果です。黄色文字のところがコミットIDです。最新のコミットIDがe4a3831で最初のコミットIDがa493688です。

最初のコミットIDの状態に戻してみます。

git checkout a493688

実行結果です。メッセージがたくさん表示されました。

以下に訳を記載します。過去に戻したのでいろいろ配慮したメッセージを出してくれていますね。ww
また、index.htmlファイルをエディターで開くと追加した<style>タグの6行がなくなって元に戻っていることがわかります。
＜翻訳＞
注: ‘a493688’ に切り替えています。
「デタッチされた HEAD」状態です。この状態では、ブランチの状態を確認したり、実験的な変更を加えてコミットしたりできます。また、この状態で行ったコミットは、ブランチに戻ることで、どのブランチにも影響を与えずに破棄できます。
作成したコミットを保持するために新しいブランチを作成したい場合は、switch コマンドに -c オプションを付けることで（今すぐでも後からでも）実行できます。例:

git switch -c <新しいブランチ名>

または、この操作を元に戻すには、次のコマンドを使用します:

git switch –

このアドバイスを無効にするには、設定変数 advice.detachedHead を false に設定します。
HEAD は現在 a493688 です [追加] 新しいファイル: index.html

以上で git が使えるようになったと思いますが、公開までもう少し時間がかかりそうです。

まとめ

　ジャイロセンサーモニターのソースコードを公開するために、まずはGitを学びました。これでGitが使えるようになったと思います。次は、GitHubを学び使えるようにしたいと思います。

コメント

タイトルとURLをコピーしました