アプリのリリースのたびにリリースタグを付けています.

タグをつけ忘れたんですが, 過去のコミットIDに対してタグを付けて, タグ情報だけPUSHできるそうなので方法をまとめます.

1. コミットに対してタグを付ける

タグを付けるコマンドはこちら

git tag tab_name commit_id

githubからタグをつけたいコミットを探して, コミットIDをコピーしましょう〜

2. タグをPUSHしてgithubにも反映させる

タグつけただけだとgithubでは見れないので, タグをPUSHする必要がある模様です.

以下でできるそうです.

git push origin tag__name

めちゃ簡単でした.

cherry-pick とは

ブランチ間で特定のコミットをマージしたいが、全部はマージしたくない場合git cherry-pickが役に立ちます。
このコマンドはコミットをつまみ食いして現在のブランチに追加します。

　　　

例えば上図のような場面でブランチaにブランチbのコミットA,Bのみを取り込みたいとします。
この時、

git checkout a
git merge b

としてしまうと、ブランチbの全てのコミットを取り込むことになります。
cherry-pickを使えば、以下のようにしてブランチbの特定のコミットをブランチaに取り込むことができます。

git checkout a
git cherry-pick Aのコミットid Bのコミットid

実際に使用した場面

cherry-pickを使用した具体的な場面について参考程度に話します。
開発の際に以下のようなフローを取っていました。

ことの発端は、開発を終えたブランチをpushしてstagingにプルリクエストを作成した際にコンフリクトを起こしたことです。
GitHub上で該当箇所を確認すると、1行修正すれば解消されるものであったため、GitHub上で直接コンフリクトを解消して、プルリクエストを送り直すことができる機能を使用しました。
その後、検証でバグが見つかったため、再度開発環境でコードを修正し、pushしたところリモートとローカルでコミットに差異があるためpullしてからpushするよう怒られます。
コンフリクトした際にGitHub上でコードを修正したことが原因なので、ここは指示に従いpullしてmergeしました。

しかし、ここでmergeした内容を確認してみると、自分がGitHub上で修正したファイル以外のファイルに関する変更が大量に含まれていることが発覚しました。
コミットログを辿ってみると、どうやらGitHub上でコンフリクトを修正した際に、一度stagingをmergeして、競合箇所を編集しプルリクエストを作成するという処理が行われていたようです。
GitHub上ではGUIで操作を行っていたため不注意な私はポチポチ押してしまい気づかない間にstagingをmergeしてしまっていました。

stagingをmergeすると何が困るかというと、stagingで検証中であった別のブランチでの変更を大量に取り込んでしまい、開発の際に思わぬバグが発生する可能性があります。
この時、開発をしていたブランチのコミットログは自分のコミットと他人のコミットが混在して以下の図のようになっていました。
　　　　　　　

git revertやら何やらをして元の状態に戻すことも考えたのですが、コミットログが荒れそうだったため（実際にはもっと混在していました）必要なコミットだけピックアップしてしまいたい...
ここでcherry-pickの出番です。

まずは開発環境でmasterからブランチを切り直します。

git checkout master
git checkout -b develop-hoge-new

次に問題のブランチ（ここではdevelop-hogeとします。）に移動してコミットログを確認します。

git checkout develop-hoge
git log

必要なコミットのidを確認して、新しいブランチでcherry-pickします。

git checkout develop-hoge-new
git cherry-pick Aのコミットid Bのコミットid Eのコミットid

とするとdevelop-hoge-newブランチに必要なコミットのみを取り込むことができます。

　　　　　　　　

あとはpushし直すだけです。

コンフリクトした箇所については競合した相手のブランチがリリースされた後にローカルのmasterブランチにてmasterをpullしてdevelop-hoge-newにmergeして解消しましょう。

参考文献

入門git

概要

wsl2というwindows上でLinux動作できる環境を利用してwin10Homeでも楽にdocker環境の構築を行いました。

IPアドレスなどVirtualBox+Vagrantで環境構築する場合は別途設定が必要だったのですが
wsl2はホストマシンと同じなので楽でした

• VirtualBoxとWSLを比較してWSLに乗り換えました

手順

OSのアップデート

wsl2は下記の要件を満たしていないと利用できないのでアップデートを行います。

バージョン 2004、ビルド 19041 以上に更新された Windows 10 を実行している。

バージョン確認は windowsロゴ + R でプログラム実行画面 → winver で実行

自動更新だと最新の状態とでてしまうので手動での更新が必要です！

• 公式サイトからアップデート

wslの有効化 & アップデート

いきなりwsl2を入れるということではなく

wslを有効化してwsl2にバージョンアップするということみたいです

管理者としてPowerShell起動

• Windows 10 用 Windows Subsystem for Linux のインストール ガイド

"Linux 用 Windows サブシステム" オプション機能を有効化 → wsl有効化

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

"仮想マシン プラットフォーム" オプション機能 → wsl2で使用する機能の有効化

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

ここで再起動をします

再度PowerShellを管理者で開いてwslの既定バージョンを2にする

wsl --set-default-version 2

WSL 2 を実行するには、カーネル コンポーネントの更新が必要です。詳細については https://aka.ms/wsl2kernel を参照してください

このメッセージがでる場合は https://aka.ms/wsl2kernel からダウンロードしてインストールしてください

再度上記のバージョン設定コマンド実行

WSL2との主な違いは～

と出たら大丈夫です！

wsl -l -v

でバージョン確認できます

Linuxディストリビューションのインストール

自分はubuntuにしたので以下はubuntu入れた場合です！

Microsoft Storeを開いてubuntuをインストール

Microsoftアカウントが必要です！

インストール後起動すると初回のみユーザー名とパスワード求められるので設定

これでwsl2の基本設定は完了

mkdir workspaceでworkspaceフォルダ作成しておく

pwd実行で下記のパスになってることを確認

/home/{ユーザー名}/workspace

ここの中でGitのリポジトリなど管理します！

エディタ

他のエディタは不明ですがvscodeで作業するものと想定します！

1. windowsにvscodeインストール（普段エディタがvscodeの場合はスキップ）
2. 拡張機能「Remote-WSL」を入れる
3. windowsからubuntu起動、作業ディレクトリでcode .を実行するとubuntu用のエディタが起動される

GitLab（GitHubもほぼ同様だと思います）

cd ~/.ssh

鍵発行（パスワード不要の場合は3回enter）

ssh-keygen -t rsa -b 4096 -C {ユーザー名}@example.com

クリップボードに公開鍵の内容をコピー

clip < ~/.ssh/id_rsa.pub

GitLabログイン
1. 右上のアカウント → settings → SSH Keys
2. クリップボードの内容貼り付け、タイトルはwsl2とかで大丈夫だと思います
3. Add key

ubuntuのコンソールに戻ってcd ~/.ssh

vi configで設定ファイル作成

接続情報記載する

~/.ssh/config

Host gitlab                                                                                                                                                                                                                                          
    HostName {Host名}                                                                                                                                                                                                                       
    User {ユーザー名}                                                                                                                                                                                                                              
    IdentityFile ~/.ssh/id_rsa                                                                                                                                                                                                                    
    Port 22                                                                                                                                                                                                                                       
    TCPKeepAlive yes                                                                                                                                                                                                                              
    IdentitiesOnly yes

これでGitLabのリポジトリをssh接続でcloneできると思います！

Docker

公式サイトからインストール

※インストール途中の Configuration は Enable WSL 2 Windows Features のチェックを外さないようにしてください。

これでubuntuでdockerが（docker-composeも）使えるようになりました！

Gitとは？

gitとは、ソースコードを始めとするファイルの変更履歴を管理するためのシステム。
変更履歴を記録するシステムのことをバージョン管理システムと言う。

フォルダに日付をつけて管理してったりすると訳わかんなくなったりするので、gitを使って管理してくのが良いみたい。

なぜGitを使うの？

ファイルの変更履歴を管理するため
何か問題があったときに過去のファイルに戻れるようにしておくため。

GitHubとは？

• gitの仕組みを利用したwebサービスのこと。
• gitの機能に対してチーム開発に便利な機能と付け加え、gitにおけるリモートリポジトリの役割も担っている。
• github上にチームで共有のプロダクト（ソースコード）を配置し、開発者はgithub上からソースコードをコピーしたり、ソースコードをgithub上のリポジトリに反映させることが出来る

世界中にコードを公開することでいろいろな方からレビューもいただけることもメリット

GitHub Desktopとは？

github desktopとは、gitを扱うためのGUIツールの一つ
github desktopは、githubが提供しているGUIツール

本来ターミナルで実施するGitの作業をGUIを用いて直感的に操作できる

リポジトリとは？

リポジトリとは、Gitで変更履歴を管理しておくための入れ物。
このリポジトリにファイルやディレクトリの変更履歴を記録しておく。

ローカルリポジトリとは？

自分のPC上（ローカル環境）に置くリポジトリのこと。
自分のPC上にあるファイルやディレクトリのバージョン管理を行いたいときに使う。

リモートリポジトリとは？

外部のサーバーなどのネットワーク上に置くリポジトリのこと。GitHubはこちらのイメージ。

リモートリポジトリのメリットは？

ネットワーク上に置くことで、複数人で管理下のファイルやディレクトリを共有することが出来る。
ローカル環境下で問題が起こったとしても、またリモートリポジトリからダウンロードを行うことで元に戻すことが出来る

クローンとは？

リモートリポジトリの内容をまるまる複製して別のマシンのローカルリポジトリを作成すること。

コミットとは？

ディレクトリやファイルの状態を記録するための操作。
コミットすることで現在の状態が、日時や変更を加えた人の情報を含めて一緒に保存することが出来る。

インデックスとは？

バージョンを記録するためにファイルを一時的に登録する場所。同じバージョンとして記録したい編集についてはまとめてインデックスに追加し、このタイミングでは記録したくない編集についてはインデックスに追加しない。
インデックスに追加したものをコミットすることで変更が保存される。変更してはコミットして、変更してはコミットしてだと何度もGitの操作が必要となり非効率ということで生まれた考え方。

コミットメッセージって何故書くの？

コミットする際に添えるメッセージのことをコミットメッセージという。
そのコミットでどのような作業をしたのかということを記録しておくために記述する。

コミット時に注意すべきこと

なるべく細かく行う。１機能１コミットがベター。ファイルをもとに戻すことになった場合、コミットごとでしか戻せないから。

プッシュとは？

ローカルリポジトリで加えた変更とリモートリポジトリに同期させること。
ローカルでコミットが終わり、リモートに変更を同期させたい場合には必ずプッシュを行う必要がある。

ブランチとは？

• リポジトリで管理をしているプロジェクトの履歴の1つ。
• 自分の作業をしている場所のこと。
• ブランチ同士は独立しているため、それぞれのブランチが干渉していない。
• 開発者ごとに担当する機能を明確に分けることが出来る
• 完成途中や問題のあるソースコードをリリースしないで済む。
• 複数人で開発する時にメインのアプリを枝分かれ（複製）させてそれぞれで開発し、終わったらメインへ結合（マージ）する。

プルとは？

リモートリポジトリの変更履歴をローカルリポジトリに反映させる操作のこと。

プルリクエスト（プルリク）とは？

作成したブランチをmasterブランチにマージをするときの確認作業のこと。
１つのブランチ作業においてコミュニケーションが取れる掲示板のようなもの
そのコードに問題が無いかどうかを他の開発者や上司に確認を行うためにプルリクエストを見て貰う。

マージとは？

ブランチとブランチを結合すること。

LGTMとは？

「コードに問題が無いので、マージをして大丈夫ですよ！」ということ

デプロイとは？

ソースコードを本番環境に設置し、稼働させること

コンフリクトとは？

複数の人が同じ箇所を編集してしまい、変更箇所を自動では判断できすにマージできなくなること。

Github Flowとは？

開発フローのルール的なもの
- masterブランチは常にデプロイ可能である
- 作業用ブランチをmasterから作成する
- 作業用ブランチを定期的にプッシュする
- プルリクエストを活用する
- プルリクエストが承認されたらmasterへマージする
- masterへのマージが完了したら直ちにデプロイを行う

同じサーバでほかの開発者が別ディレクトリで開発をしている場合のgitの設定についてまとめる。

globalはhomeディレクトリ内にあるユーザディレクトリ全体に反映させる

対象リポジトリだけに設定を反映させたい場合は、以下の通り。

git config --local user.name
git config --local user.email

以上

同じサーバでほかの開発者が別ディレクトリで開発をしている場合のgitの設定についてまとめる。

globalはhomeディレクトリ内にあるユーザディレクトリ全体に反映させる

対象リポジトリだけに設定を反映させたい場合は、以下の通り。

git config --local user.name
git config --local user.email

以上

下記の企画の4日目です。
【１ヶ月で学ぶ！】Back-end Developperへの道 #0:導入

下記を参考に項目を作成しました。
Roadmap to becoming a web developer in 2020

Version Control Systemsとは

Basic Usage of Git

• プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システム
• 2005年に公開され、現在はGoogle所属の日本人濱野純によってメンテナンスされている。
• 動作速度に重点が置かれており、主にC言語で作成されている。

Repo hosting services

GitHub

https://github.com/

• ソフトウェア開発のプラットフォームであり、ソースコードをホスティングする
• ソースコードをホスティングすることで複数人のソフトウエア開発者と協働してコードをレビューしたり、プロジェクトを管理しつつ開発を行うことができる。
• SNS機能をもち、feeds、followersとして提供されている

GitLab

https://about.gitlab.com/

• CI/CDやdockerへの対応など、Githubを先に行くような機能追加が積極的
• GitLab CI/CDでは、テスト・ビルド・デプロイを自動化することができる
• DockerコンテナイメージをGitLabの継続的統合ツールに統合することができる

Bitbucket

https://bitbucket.org/

• プライベートリポジトリを無制限に持てる無料アカウントを提供している
• Djangoを用いて開発されている

参照

Git - ウィキペディア
GitHub - ウィキペディア
GitLab - ウィキペディア
Bitbucket - ウィキペディア

リポジトリ

リモートリポジトリを登録

git remote add origin URL

リモートリポジトリURL確認

git remote -v

ブランチ

ローカルブランチの一覧

git branch

リモートブランチ一覧

git branch --remote

ローカル・リモートブランチ一覧

git branch --all

ブランチ作成

git branch ブランチ名

ブランチを新規作成&チェックアウト

git checkout -b ブランチ名

リモートにブランチを登録

git push -u origin ブランチ名

対象ブランチにチェックアウト

git checkout ブランチ名

マージしたブランチ削除

git branch --delete

マージしたかどうかに関わらず削除

git branch -D ブランチ名

リモートブランチ削除

git push --delete origin ブランチ名

ワーキングツリーの状態確認

普通に表示

git status

短く表示

git status -s

ステージング（インデックスにコミットするファイルを登録）

指定したファイルを登録

git add ファイル名

現在のディレクトリのファイルすべてを登録

git add .　

スタッシュ

待避にコメントをつける

git stash save コメント

退避させた変更の一覧

git stash list

退避させた最新の変更を戻す

git stash apply

指定する退避させた変更を戻す

git stash apply 番号(git stash list の番号)

コミット

コミット

git commit -m コメント(-m コメント)
* -m 2つで2行にできる

前回コミットした時点に戻す

git reset --hard HEAD

特定のコミット時点に戻す

git reset --hard ハッシュ値(git logで確認できる)

一つ前のコミットメッセージを修正する

git --amend -m コメント

プッシュしたコミットメッセージをリモートリポジトリに再プッシュする

git push -f origin ブランチ名

プッシュ

リモートリポジトリにプッシュ

git push origin ブランチ名

強制的にプッシュ

git push -f origin ブランチ名

マージ

ローカルでマージ済ブランチ一覧表示

git branch --merged

対象ブランチをチェックアウト中のブランチへマージ

git merge ブランチ名

新しくマージコミットを作成してマージ

git merge --no-ff ブランチ名

プル

リモートの変更を取得

git pull origin ブランチ名

その他

.gitignore作成

touch .gitignore

個人的に、エンジニアたるものgitぐらいは使えないとな〜と思っていたのですが、自分の周りにGitをちゃんと使える人も少なくてなかなか手が出ませんでした。
しかし、最近kindle UnlimitedでサルでもわかるGit入門という本を見つけたので、読んで触ってみてGitの素晴らしさに気付きました。
Git初心者がGitを触ったことがない人に伝えられることも多いとおもいますので、備忘録として書いていきます。
こういう使い方がただしいよ〜とか便利だよ～みたいなのがあれば教えていただけるとありがたいです！

Gitとは

gitとは、バージョン管理システムのことでファイル単位でバージョンの管理を行なっていくことができます。
今までの自分もそうだったのですが、バージョン管理システムを使わないと、ファイル名にver1とかをつけていくのですが、最終的にどれが最新版だったかわかりにくくなったり、ファイル数が増えすぎてよくわからなくなってしまいます。
そこで、gitを使うと簡単にバージョン管理を行なっていくことができます。
gitを使って「コミット」をするとセーブポイントをたくさん作っていくことができ、簡単にセーブポイントに戻ることができます。
また、誰がいつなぜそうしたのかをメモしておくことができるので、グループの開発等にも多く使われています。

Gitを使い始めてからは、どのファイルだったっけと思うことも少なくなり、管理楽になりました。
今は、作業がひと段落するとコミットをしてセーブポイントを作っておくことが習慣化してきて、本当に最高です。
では、実際にgitの使い方をみていきましょう。

Gitの基本的な使い方

まずはgitで管理したいディレクトリに行って最初の初期設定を行う必要があります。
ターミナルで、管理したいディレクトリで以下を実行します。

ターミナル

$ git init

これで、自動的に初期設定を行なってくれます。
これをすると、ディレクトリ内に.gitフォルダが作成されているハズです。
この中にconfigファイルとかの設定ファイルがまとめられています。簡単ですね！

次は、セーブポイントを作っていくのですが、まずどのファイルにセーブポイントを作るかを選択します。
変更をしていなければ、そのファイルのセーブポイントを作る必要はないためです。

ターミナル

$ git add hogehoge

こんな風に一つずつやっても良いのですが、gitは全てを選択すると、変更があったファイルだけ勝手にセーブしてくれます。すごい！
以下のコマンドで全てを選択してくれます

ターミナル

$ git add -A

ここまでは、セーブポイントを作るまでの前段階です。
セーブするために教会に向かいました！って感じです。
次にちゃんと神父さんに話しかけて、セーブします。

ターミナル

$ git commit -m "ここになんでセーブしたかのコメントをかく"

これでセーブポイント作ってくれます。
思ったよりも簡単ですね。

commitするタイミングっていつ？

初めて触る人にとって、知りたいのはどういうときにコミットするの？というところですよね。
僕自身まだまだ初心者なので、手探り状態ですが作業が一段落ついたらコミットをすればよいと思います。
何かしらの機能を実装した、関数を新しく作成した、ええ感じになった、みたいなときにコミットすれば大丈夫だと思います。
gitの利点の一つは、しっかりとコメントを残せるというところです。
正直、一か月前に書いたコードはほぼ他人が書いたコードです。
どういう目的で実装したとかも残せるので、非常に良いですね。

個人で使うのであれば、ここまでできれば正直十分だと思います。
しかし、これだけではgitを使いきれていません。
いままでやっていたのはセーブの一つのスロットにセーブしている感じです。
ちゃんと履歴は残っていて良いんですが、何かあった時のために別のセーブスロットでいろいろチャレンジして、いつでも大元に戻れるようにしておきたいですよね！
複数のセーブスロットを用意できるのがbranchというものになります。
ブランチを切るみたいな言葉を聞いた方も多いのではないでしょうか。
次にブランチについてまとめていきます。

Branchとは？

ブランチとは枝という意味で、もともとのコミットの道筋から分岐を行ったもので、ブランチ毎に目的を分けるなどを行うことで、それぞれの作業に影響を与えることなく、別々の作業を行うことが可能になっています。
もちろん、ブランチ毎にコミットを行うことができてブランチ毎にセーブポイントが作れます(すごい！)。
正直、一人で作業しているときに使うものか？と言われれば疑問は残りますが、グループでのコーディングでは非常に重要になってくるので覚えておいて損はないと思います！(ちゃんとグループで使ったことはないんですけどね！)
まずは、ブランチをを作成してみましょう。ブランチを作るのは非常に簡単です。
まずは、hogehogeというブランチを作ってみましょう！

ターミナル

$ git branch hogehoge

これでhogehogeブランチが作成されています。
実際に作成されているか確認してみましょう！
git branchと入力すると現在自分がいるブランチとほかのブランチの一覧が出てきます。*がついているのが現在のブランチです。

ターミナル

$ git branch
  hogehoge
* master

新しく、hogehogeが作成されていますが、自分がいるのがmasterブランチになっています。
なので、hogehogeで作業をするには、切り替える必要があります。
切り替えると、hogehoge上で作業をすることができます。

ターミナル

$ git checkout hogehoge
Switched to branch 'hogehoge'
$ git branch
* hogehoge
  master

これで切り替えることができました！
後は、今までと同様にコミットをしていけば大丈夫です！
ここで、気を付けないといけないのはブランチは分岐点を作っていくので、分岐点を作る場所っていうのが重要になっていきます。
ちゃんとした場所でブランチを使わないとマージをするときに影響が出るかもしれないので、大変ですね。
ここで、新しくマージという言葉が出てきましたが、マージは作成した分岐をもとのブランチに融合するためのモノです。
では適当にいろいろ変更をコミットした後にマージをしてみましょう。
マージは分岐元でする作業なので、まずはmasterブランチに移動しましょう。
checkoutで移動できるんでしたね。

ターミナル

$ git checkout master
Switched to branch 'master'
$ git branch
  hogehoge
* master

ちゃんと移動できましたね。
では、次にマージをしてみましょう。
コマンドで、マージしたいブランチを入力しましょう！

ターミナル

$ git merge hogehoge
Updating 9f0fc05..8070d7e
Fast-forward
 README.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

これで、masterブランチにhogehogeブランチ上での作業が反映されました！
そんなに難しくはないですね。
ブランチは大きな作業毎とか、Issue事にbranchを作成すると管理がしやすいと思います。
こういうブランチ管理の考え方というのも複数あって、git-flowとgithub-flowという考えかたがあるので、調べると情報が出てくるのでそれをよく読んでみると良いと思います。
個人的には、github-flowから始めるとわかりやすくて良いと思います！

最後に

僕自身完全に独学でやっているので、間違えもあると思います。
そこらへんはコメントで指摘いただけるとありがたいです。
個人で使うときでも便利ですが、多くの人と作業するときにより強みを感じると思います。
次は、リモートリポジトリの使い方でもまとめてみようと思います。

gitのローカルでファイルの変更点を一度全てキレイにしたい場合や
ステージ前の新規追加ファイルを削除する時のメモです

バージョン管理内のファイルの変更点をリセットする場合

git checkout .

バージョン管理外（未ステージ）のファイルの追加分をリセットする場合

git clean -df .

git clone を実行する前に、リモート先（リポジトリ URL 先）の HEAD（現在の最新コミット・ハッシュ値）を取得したい。

「git clone リモート先の HEAD 取得 確認」でググってもドンピシャのタイトルの記事がなかったので、自分のググラビリティ備忘録として。

TL; DR

git の ls-remote コマンドで、リモート先の諸情報を得られます。例えば、ヘッダー情報は --heads オプション。

ロング・オプション

git ls-remote --heads [ リポジトリのURL ]

ショート・オプション

git ls-remote -h [ リポジトリのURL ]
# URLが指定されていない場合はヘルプ表示になるので注意

使用例

$ git ls-remote --heads https://github.com/KEINOS/TPL-PHP-HelloWorld.git
b05c14a0ee5651990eec41e6bd397a19726d9440        refs/heads/master

TS; DR

Travis CI／Circle CI／GitHub Actions といった CI の実行処理で、いくつかのリポジトリを git clone する必要がありました。

ローカルではなく、CI の処理上で各々のリポジトリを clone し、必要なデータをコピー＆マージしてからデプロイ（リリース）する必要があったからです。特に cron などでスケジュール実行される自動化されたデプロイです。

しかし、各々のリポジトリのサイズが大きいため、対象のリポジトリに変更があった場合のみ clone するように限定したいのです。そのため、最終コミットのハッシュ値（HEAD）を比較するのが合理的です。

git pull など clone 済みの場合のヘッダを確認する記事は多いのですが、git clone 前にヘッダを取得する記事がなかなか見つからず。git の公式ドキュメントを読み漁あさってたらドンピシャの情報がありました。

NAME
git-ls-remote - List references in a remote repository
^{（git-ls-remote - リモートリポジトリの参照情報を表示する）}

SIMPSONS

構文

git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>]
              [-q | --quiet] [--exit-code] [--get-url] [--sort=<key> ]
              [--symref] [<repository>[<refs>…​] ]

DESCRIPTION
Displays references available in a remote repository along with the associated commit IDs.
^{（関連するコミットIDとともに、リモートリポジトリで利用可能な参照情報を表示します）}

• git-ls-remote | Document @ Git

昨日、作業ブランチにpushする時の入力は面倒だけど、pushするブランチは確認したいを書きましたが、
よくよく考えてみたらコミットの段階で確認出来た方が良い事に気が付いたので、そのシェルスクリプトを作ってみました。

作ったもの

• commit時に現在ブランチ、入力したコメントが出力される
• y or Yの入力でコミットされる
• 修正されたファイルの一覧が見れる

addしないままコミットしてしまうこともあったので、修正ファイルも表示されるようにしました。

~/.bashrc

gitcommit(){

    branch=`git rev-parse --abbrev-ref HEAD`
    if [ -z $branch ]; then
        return
    fi

    git status

    comment=$1
    if [ -z $comment ]; then
        echo '>> Comment is Required.'
        return
    fi

    echo "[branch]  $branch"
    echo "[comment] $comment"
    read input

    if [ -z $input ]; then
        return
    fi

    if [ $input = 'y' ] || [ $input = 'Y' ]; then
        git commit -m $comment
    else
        return
    fi

}

gitcommt <COMMENT>で実行します。

Ariel:bash gatapon$ gitcommit
On branch gt.test
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   first.txt

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

    modified:   test2.txt

>> Comment is Required.

コメントがなければ終了する。

Ariel:bash gatapon$ gitcommit コミットしてみる
On branch gt.test
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   first.txt

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

    modified:   test2.txt

[branch]  gt.test
[comment] コミットしてみる

現在のワークスペースとステージの状況が表示され、現在のブランチとコメントが確認できる。
y or Yを入力すると実行

[branch]  gt.test
[comment] コミットしてみる
y
[gt.test 6d163de] コミットしてみる
 1 file changed, 1 insertion(+)