・Gitコマンドに慣れるのは凄く大事です （適当すぎる見出し）
エンジニアとしてチームで何かしらのプロジェクトを推進する際に、gitを使用して変更履歴の確認やチームメンバとコードを共有するという作業は、絶対に避けては通れない道です。
あくまで自分用の基礎の復習、備忘録なので殴り書き方式でいきます。
自身の作ったソフトウェアを格納するディレクトリが、カレントディレクトリであることを想定します。
※ 環境はUbuntu 20.xxです。
・Git管理用GUI（gitk）について
Gitコマンドをつらつら説明する前に、Git管理用GUI「gitk」について軽く触れておきます。
下記は、Git管理用のGUI「gitk」をインストールするコマンドです。
apt-get install git-gui gitk
そのあと、
gitk
これにより、Git管理用のGUIが出てきます。
ターミナルでのCUI操作とGUI操作、どっちにも慣れておくことが理想と思います。
GUIでの操作方法はこの記事では割愛しますが、以下のコマンドを一通り覚えれば難なく使いこなせちゃうと思います。
以下にGit管理にて使用頻度の高いコマンドをまとめます。
・ローカルリポジトリをGitリポジトリとして初期化する
| コマンド | 説明 |
|---|---|
| git init | 初めてのプロジェクトを作成する（ディレクトリをGitリポジトリとして初期化する） |
上記により、カレントディレクトリを「Gitリポジトリ」として初期化します。
「今からここ（カレントディレクトリ）を新しい作業場（の出発地点）とする！」 みたいなニュアンスです。
・ブランチ名（作業場の名前）を設定し、そこに移動する
何かしらプログラムを作り、チームメンバと共有することになりました。
メンバーと作業場を共有するために「作業名 = ブランチ名」を決める必要があります。
命名は自由ですが基本「遂行するプロジェクトの名前」だったり「お試し機能を実装してみたw」等の意味付けをします。
原則英語です。今回はベーシックな感じに「Project_0213」というブランチ名をつけます。
| コマンド | 説明 |
|---|---|
| git checkout -b [branch name] | 新規ブランチを作成してチェックアウト |
なので今回の場合、
git checkout -b Project_0213
checkoutは基本「移動」する為のコマンドですが、オプションコマンドの -b を一緒に使うことで ブランチを新規に作成しつつ、そのブランチに移動します 。
・作成したファイルをステージング（add）する
そこであなたは「script_verBeta.py」を作成しました。
なんて素晴らしい出来だ！早くみんなに見せつけたい！
チームメンバと上記Pythonファイルを共有する準備をします。
| コマンド | 説明 |
|---|---|
| git add [file name] | 指定したファイルをステージングエリアに追加する |
| git add . | カレントディレクトリ内のすべてのファイルをステージングエリアに追加する |
| git restore --staged [file name] | 指定したファイルのステージングを取り下げる |
| git restore --staged . | ステージング内容の全てを取り下げる |
なので今回の場合、
git add script_verBeta.py
これで、 「ステージング」 という作業が完了します。一時保存のようなイメージです。
・ステージング（add）したファイル（commit）をコミットする
次にaddで「ステージング」したファイルをcommitで「コミット」します。
急に英語とカタカナを並べまくって恐縮ですが、
「ステージング（add）」は 作成したファイルや変更を、「自分用」としてローカルリポジトリに一時的に保存する。（かつ、コミットの準備）
「コミット（commit）」は 作成したファイルや変更を「自分用兼、他メンバー用」としてローカルリポジトリに正式に保存する。（次の作業（push）で他メンバーへ「何のファイル、何の変更？」か伝える必要がある為、コメントが必須）
（補足）ChatGPT先生に聞いたら超分かりやすい例え出てきた
科学の進化ってすげー...
以下コミット関連のコマンドです
| コマンド | 説明 |
|---|---|
| git commit -m “Comment“ | ステージングした内容をローカルリポジトリに記録する（""内にコメント） |
| git restore [file name] | 特定のファイルを元の状態（コミット時の状態）に戻す |
| git reset --soft HEAD~ | 直前のコミットを取り消し、変更をステージングに戻す |
| git reset --mixed HEAD~ | 直前のコミットを取り消し、変更をワーキングディレクトリに戻す |
| git commit --amend | コミットメッセージを修正する（修正後Ctrl＋X→Y→Enter） |
なので、今回の場合
git commit -m "Init: 新規のスクリプトファイル"
みたいな感じに入力してローカルリポジトリへ「正式」に保存します。
コメントには「Add：○○」「Fix：○○」「Test：○○」等、 ジャンル（プレフィックスといいます）を英語で書き、コロンの後に詳細を記入するパターンを現場でよく見かけます 。
追記：プレフィックスは履歴の見やすさや開発効率に直結する為、リストでもう少し詳しく紹介します。
| プレフィックス | 説明と例 |
|---|---|
| Add: | 新機能やファイルの追加（Add: ログイン機能を追加） |
| Fix: | バグ修正（Fix: ユーザープロフィールが正しく表示されないバグを修正） |
| Update: | （バグ修正の範囲外で）機能の改善・リファクタリング（Update: パフォーマンス向上のためSQLクエリを最適化） |
| Change: | 仕様変更（Change: パスワードの最小文字数を6→8に変更） |
| Refactor: | コードのリファクタリング（動作に影響なし） （Refactor: 重複コードを関数化） |
| Remove: | 不要な機能やコードの削除（Remove: 使われていない関数を削除） |
| Docs: | ドキュメントの変更（Docs: READMEにセットアップ手順を追加） |
| Test: | テスト関連の追加・修正（Test: ログイン機能の単体テストを追加） |
| Chore: | その他（ビルド設定変更・CI/CD設定変更など）（Chore: GitHub Actionsのワークフロー修正） |
| Hotfix: | 緊急のバグ修正（Hotfix: 本番環境で発生したエラーの修正） |
| Style: | コードのフォーマット修正（機能には影響なし）（Style: インデントをスペース4つに統一） |
| Revert: | コミットの取り消し（Revert: 先ほどの変更を元に戻す） |
誤ったファイルをコミットしてしまった場合、 git restore 等のコマンドで一旦一歩引きます。
また、コメントを修正する場合のコマンドを入力した場合、ターミナルが「コンテナ」という世界に連れていかれますが、
自分が入力したコメントらしきものを編集したら、Ctrl＋X→Y→Enterでコンテナから脱出できます。
また、コミットが正常完了した段階でもまリモートリポジトリ（メンバーと作業内容を共有する領域）には影響を及ぼしません。
ローカルリポジトリの範囲内で完結しています。
・コミット（commit）した内容をリモートリポジトリに反映（push）させる
いよいよ自分の作成したスクリプトをリモートリポジトリに反映（push）させて、他メンバーに見てもらいます。ドキドキするねぇ！
| コマンド | 説明 |
|---|---|
| git push [repository] [branch name] | ローカルリポジトリの変更をリモートリポジトリに反映させる |
[repository] の箇所は基本デフォルト名で設定される「origin」で大丈夫と思います。
[branch name] は「Project_0213」でしたね。
git push origin Project_0213
# この後、ID/PASSの入力が必要な場合がほとんどです
これでいよいよチームメンバに「ほえーscript_verBeta.pyっていうの作ったんや」と気付いてもらうことができます。
つまり、 git pushが完了することでようやく 自分がローカルリポジトリにて何かしら作成・変更をしたことをリモートリポジトリという場で、メンバと共有できます。
originはリモートリポジトリのルート部のデフォルト名ですが、変更されている場合もあります。
もし「該当するリモートリポジトリが見つからない」といったエラーが返ってきたら、
git remote -v でリモートリポジトリの一覧が確認できるので、それに合わせて（プロジェクトメンバーと相談の上）pushし直してください。
もし「リモートリポジトリが一つもない」というエラーが返ってきたら（プロジェクトメンバーと相談の上） git remote add origin <任意のリポジトリのURL> でリモートリポジトリを新規に作成してあげてください。
プロジェクト推進開始時期に、 先にリモートリポジトリのルート部を git remote rename origin [別の名前] のように変更するケースも想定されます。
pushまでの一連の流れは以上ですが、各コマンドの実行前に、今Gitリポジトリがどういう状況なのか時々確認しておくと安心です。
| コマンド | 説明 |
|---|---|
| git status | どのファイルがステージングされているか、また変更があるかチェックできる。 |
| git log | リポジトリの履歴を確認する。過去のコミットメッセージや変更履歴が表示される。 |
| git log --oneline | logを一行ずつ表示 |
commitやpushする前に確認する癖をつけましょう。（自分に言い聞かせてる）
また、ブランチが複数あり移動したい場合は
| コマンド | 説明 |
|---|---|
| git checkout [branch name] | 指定したブランチに移動する |
序盤にも出てきましたね。 -b をつけると、指定したブランチを名を新規に追加しつつ移動します
また、チーム開発に必須なものとして merge, pull コマンドがあります。
次回記事にて簡単に説明します。⇒【Git操作編②】
自分は個人開発が多くこいつらにあまり馴染みがないため、あんま自信ないです。
復習兼備忘録なので、参考程度に見ていただければと存じます。
おわり