20201208のGitに関する記事は12件です。

投稿日：2020-12-08T23:59:24+09:00

GitGuardianから警告がきて焦った話

はじめに

以前GitHubにrailsアプリを作成した直後にpushしたらこんなメールが届きました。

どうやらGitGuardianから「あなたの〇〇というリポジトリでrailsのシークレットキーが検出したよ。不正利用されるかもしれないからGitHubにログインしてリポジトリを保護してね。」というニュアンス。
慌ててリポジトリやrailsアプリを調べてみると、.gitignoreが生成されていないことが判明。
本来Gitの管理対象外にされているmaster.keyまでpushしてしまったことが原因だと考えられます。

普段はMacで開発しているのですが、この日は諸事情で大学生協指定のWindowsで開発していました。
Macならrails newした段階で自動的に.gitignoreが自動生成されますが、どうやら大学生協指定のwindowsだと生成されず手動で作る必要があったんですね。

ありがたやと思って調べてみても、思いのほかGitGuardianについて書かれている記事がないため執筆にあたりました。
環境変数など機密鍵を管理する方法はこの記事では解説しないので、ご自身で調べてください。

GitGuardianとは

GitGuardianのホームページ
https://www.gitguardian.com/

簡単に言えば、GitHubで公開されているリポジトリにAPIキーや機密情報（以下機密鍵）などが含まれていないかチェックしてくれるサービスです。（他にもあるのですが）

Dockerの創業者も出資し、世界中の開発者15万人から信頼されているシステムのようですね。
皆さんが普段何気なく利用しているリポジトリも、常にGitGuardianが監視してくれています。
GitGuardianはGitHubにpush（commitも）した時に、リポジトリ内に機密鍵が含まれていないかをチェック。
もし検出されたら私のように警告メールで知らせてくれます。
実は警告メールきたことある人結構いそう（な気がする）
GitGuardianは一日になんと数千を超える認証情報のリークを検出するらしいです。
本当に偉大なサービスですね。

当たり前ですが、GitHub上で機密情報を感知するのはGitGuardianだけでなく、悪意のあるbotや人間もいます。
その上GitHubで見つけた機密情報を交換し合う悪い集団もいるとのこと。
こちらの記事では検証でAWSのキーペアをわざとGitHubに公開し、わずか13分で不正入手されたらしいです...

皆さんも機密鍵の管理には十分気をつけましょう。
そしてGitHubに登録したメールを一度確認してみてください。もしかしたら警告メールが届いているかもしれません...

今日はここまで。随時更新していきたいと思います！

参考

GitGuardian

GitHubのリポジトリー上に機密情報や脆弱性を見つけるGitGuardianにDocker創業者らが投資

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T23:59:24+09:00

GitGuardianから警告メールがきて焦った話

はじめに

以前GitHubにrailsアプリを作成した直後にpushしたらこんなメールが届きました。

どうやらGitGuardianから「あなたの〇〇というリポジトリでrailsのシークレットキーが検出したよ。不正利用されるかもしれないからGitHubにログインしてリポジトリを保護してね。」というニュアンス。

慌ててリポジトリやrailsアプリを調べてみると、.gitignoreが生成されていないことが判明。
本来Gitの管理対象外にされているmaster.keyまでpushしてしまったことが原因だと考えられます。

普段はMacで開発しているのですが、この日は諸事情で大学生協指定のWindowsで開発していました。
Macならrails newした段階で自動的に.gitignoreが自動生成されますが、どうやら大学生協指定のWindowsだと生成されず手動で作る必要があったんですね。

rails newした程度のアプリだったのでAPIキーなどは記載されていませんでしたが、本当に本当に本当に反省しました...

ありがたやと思って調べてみても、思いのほかGitGuardianについて書かれている記事がないため執筆にあたりました。

*環境変数など機密鍵を管理する方法はこの記事では解説しないので、ご自身で調べてください。

GitGuardianとは

GitGuardianのホームページ
https://www.gitguardian.com/

簡単に言えば、GitHubで公開されているリポジトリにAPIキーや機密情報（以下機密鍵）などが含まれていないかチェックしてくれるサービスです。（他にもあるのですが）

Dockerの共同創業者も出資し、世界中の開発者15万人から信頼されているシステムのようですね。
皆さんが普段何気なく利用しているリポジトリも、常にGitGuardianが監視してくれています。
GitGuardianはGitHubにpush（commitも）した時に、リポジトリ内に機密鍵が含まれていないかをチェック。
もし検出されたら私のように警告メールで知らせてくれます。

GitGuardianは一日になんと数千を超える認証情報のリークを検出するらしいです。
本当に偉大なサービスですね。

当たり前ですが、GitHub上で機密情報を感知するのはGitGuardianだけでなく、悪意のあるbotや人間もいます。
その上GitHubで見つけた機密情報を交換し合う悪い集団もいるとのこと。
こちらの記事では検証でAWSのキーペアをわざとGitHubに公開し、わずか13分で不正入手されたらしいです...

GitGuardianはこのような輩から守ってくれるまさに守護神です。

最後に

GitGuardianはあくまで最後の砦です。
お世話にならないよう、皆さんも機密鍵の管理には十分気をつけましょう。
pushした際に少しでも不安な部分があれば、警告メールが来ていないか確認してみるといいのかもしれません。

そして今GitHubに登録したメールを一度確認してみてください。もしかしたら警告メールが届いているかもしれません...

今日はここまで。最後までお読みくださってありがとうございました。

参考

GitGuardian

GitHubのリポジトリー上に機密情報や脆弱性を見つけるGitGuardianにDocker創業者らが投資

GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T23:55:20+09:00

用語メモ（バージョン管理関連など）

用語メモ

.gitignore
gitでのバージョン管理において無視するファイルまたはディレクトリを指定

composer.json
パッケージと条件が書かれているJSONファイル

composer.lock
composer.jsonからインストールされた情報が記述されている
lockを利用して同じ環境を作ることが可能

今日の名言

What do you want meaning for? Life is desire, not meaning.
（なぜ意味なんか求めるんだ？人生は願望だ、意味ではない）

-チャーリー・チャップリン

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T23:54:07+09:00

Git/GitHubの初期操作に触れてみた(@Python/Django)

はじめに

今回は、Python/DjangoにてWebアプリを作成する過程で扱う
Git/GitHubの初歩的な初期操作について簡潔に確認していきます。

【前工程】
・djangoプロジェクト作成はこちら
・Git初期設定はこちら

GitHubの初期操作

基本的には以下のように、公式のsetupに推奨される手順通り、コマンドを実行していきます。これらを実行することで、ローカルのプロジェクトを保存することから、Web上のGitHubへUPするところまで行います。

※事前にGitHubにサインインし、「+」マークから「New repository」を選択し、任意のリポジトリ名を付けて「Create」しておきます。

①リポジトリの作成
$ git init
②コミット対象を指定
　今回の場合、"."とすることで、カレントディレクトリ以下の全てのファイルを対象としています。
$ git add .
③ローカルに保存する
　"first commit"という名前でローカルに保存します。
$ git commit -m "first commit"
④ローカルのブランチ名を変更する
$ git branch -M main
⑤事前に作成しておいたGitHubのリポジトリを使用してリモートリポジトリを追加する
$ git remote add origin https://github.com/指定のリポジトリ名/
誤って追加した場合の削除は以下の通りです。
$ git remote rm origin
⑥GitHub上にプッシュする(Web上にUPする)
$ git push -u origin main
ここでうまく実行されない場合は、
初期設定がうまくいってない可能性があるため、
再確認し再度実行してみます。

GitHub上で"Success"と表示され完了しました。

まとめ

今回は、Webアプリを作成する際、事前のプロジェクト作成後のGit/GitHub初期操作を確認しました。

Python/djangoによるWebアプリ作成の過程で、さらにGit/GitHubについて掘り下げていきたいと思います。

ありがとうございました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T23:54:07+09:00

Git/GitHubに触れてみた(@Python/Django)

はじめに

今回は、Python/DjangoにてWebアプリを作成する過程で扱う
Git/GitHubの初歩的な初期操作について簡潔に確認していきます。

【前工程】
・djangoプロジェクト作成はこちら
・Git初期設定はこちら

GitHubの初期操作

基本的には以下のように、公式のsetupに推奨される手順通り、コマンドを実行していきます。これらを実行することで、ローカルのプロジェクトを保存することから、Web上のGitHubへUPするところまで行います。

※事前にGitHubにサインインし、「+」マークから「New repository」を選択し、任意のリポジトリ名を付けて「Create」しておきます。

①リポジトリの作成
$ git init
②コミット対象を指定
　今回の場合、"."とすることで、カレントディレクトリ以下の全てのファイルを対象としています。
$ git add .
③ローカルに保存する
　"first commit"という名前でローカルに保存します。
$ git commit -m "first commit"
④ローカルのブランチ名を変更する
$ git branch -M main
⑤事前に作成しておいたGitHubのリポジトリを使用してリモートリポジトリを追加する
$ git remote add origin https://github.com/指定のリポジトリ名/
誤って追加した場合の削除は以下の通りです。
$ git remote rm origin
⑥GitHub上にプッシュする(Web上にUPする)
$ git push -u origin main
ここでうまく実行されない場合は、
初期設定がうまくいってない可能性があるため、
再確認し再度実行してみます。

GitHub上で"Success"と表示され完了しました。

まとめ

今回は、Webアプリを作成する際、事前のプロジェクト作成後のGit/GitHub初期操作を確認しました。

Python/djangoによるWebアプリ作成の過程で、さらにGit/GitHubについて掘り下げていきたいと思います。

ありがとうございました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T23:27:31+09:00

gitでプッシュする前に確認すべきこと

この記事を書こうと思ったきっかけ

最近gitを使ったチーム開発し始めたが、あまりにも凡ミス、初歩的なミスをしまくり先輩エンジニアにこってり叱られたので、自分でpushする前のチェック項目を作成すればミスる可能性が減ると思って書きました

対象読者

gitを最近触り始まて、怯えながらgit pushしているエンジニアに向けてます

チェック項目

大前提

コードのコメントアウトの内容が適切であるか

変数名、関数名、クラス名はネーミング定義にそっているか。特になければ'言語　ネーミングルール`などでググっていい感じのルールを探す。Pythonならpep8などを参考にする。

Pythonに限るがドックストリングの内容は簡潔に記載されているか。書き方など特に指定なければこちらの記事を参考に記載する。

不要なコードはないか。例えば確認用に記載したprintやTODOのコメントなど

修正内容がきちんと修正されているか。（プルリクで却下された内容に対応した修正となっているかなど）

git addする前

git statusで追加したいファイルが赤文字になっているか確認する。

余計なファイルがないか確認する。ある場合は追加したい対象のファイルのみをaddする

git add後

git statusで追加したファイルが緑文字になっているか確認する。

余計なファイルがないか確認する。ある場合はgit addの取り消しを行う。取り消し方法はこちら参照

問題がなければコミットを行う。
git commit -m '修正内容'
git commit後

git statusで追加したファイルが表示されていないことを確認する。

git logで的外れなコメントをしていないか確認する

問題がなければ'git pull origin master'を行う。

問題がなければ'git pull origin master'を行う。（超重要！！）

git push後

BacklogやGitBabやGitHub等で自分の追加・修正箇所が反映されていることを確認する。

その他

この項目も確認した方がよいなどあればコメントいただけると助かります！

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T21:42:11+09:00

Git/GitHubの初期設定について簡潔に触れてみた

はじめに

Python/DjangoでWebアプリ作成を行う過程で、
必要不可欠なバージョン管理システムGitについて
今回は、簡潔に触れていきます。

初期設定

初期設定を行います。ターミナルを起動。

※公式サイトにてアカウントを作成しておきます

①アカウントのユーザー名を登録
　以下のコマンドを実行します。
$ git config --global user.name "ユーザー名"
②アカウントのメールアドレスを登録
　以下のコマンドを実行します。
$ git config --global user.mail gihub@example.com
③使用したいエディターを登録
　以下のコマンドを実行します。※VSCodeの場合
$ git config --global core.editor "code --wait"
　""の中は、エディターによって変更します。
　例：Atomであれば、"atom --wait"

④設定内容を確認
　以下のコマンドを実行します。
$ git config --list 
設定が反映されていることを確認できます。
以下のコマンドで設定ファイルを確認することも可能です。
$ cat ~/.gitconfig
まとめ

Git/GitHubの初期設定を確認しました。

Gitの基本的なコマンド操作や、ブランチ・マージ・プルリクエスト等についても、内部の動きまで理解を深めていきたいと思います。

ありがとうございました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T21:01:36+09:00

プルリクエストを出すときに意識すること

今回はプルリクエスト(以下PR)を出すときに意識したいことをまとめておきます

PRを出す前に確認すること

プルリクエストの粒度は適切か

不明瞭なところにコメント(意図)は入れてあるか

nullやundefinedで落ちるようなコードになっていないか

テストは書かれているか

エラーを握りつぶしていないか

リファクタリングできるところはないか

無駄なコードは消しているか

変数はできる限りローカルに閉じる事ができているか

コードや名前に一貫性はあるか

完了してから５分は様々な操作を繰り返したか

処理後のデータに誤りはないか

未確認の仕様はないか

書くべきこと

チケットへのリンク

解決したこと(受け入れ条件、仕様)

解決していないこと(理由)

ページのキャプチャ、GIF画像

備考、伝達事項

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T17:14:07+09:00

pushした一部ファイルの取り消し方

経緯

タスクを作りリモートにpushしてレビュー出そうとしたところ、
Gemfile.lockとschema.rbの差分もpushしてしまっていることに気付きました。

自分が入れたgemじゃないし、今回はタスク追加の変更のみpushしたかったので、Gemfile.lockとschema.rbの差分pushをなかったことにします。

ログの確認　→　コミット巻き戻し　→　手直し →　force push　という手順で行います。

まずログの確認
$ git log
commit commitID # 今回pushしたもの
Author: author name
Date:   Fri Dec 4 18:48:13 2020 +0900

    タスクの追加

commit commitID # ここの状態に戻す
Author: author name
Date:   Fri Dec 4 15:06:53 2020 +0900

    ロジック削除

commit commitID
Author: author name
Date:   Fri Dec 4 14:57:10 2020 +0900

    中央揃えにする
コミット巻き戻し

「# 今回pushしたもの」の一つ前、「# ここの状態に戻す」ところにgit resetで状態を戻します。
git reset commitID

git resetにはオプションがあって、
git reset --soft commitID → ワーキングツリー* の変更とステージング* の状態はそのまま残る。
--hard →　どちらの内容も消える。
--mixed →　デフォルトはこれ。ワーキングツリーの変更は残るがステージングの状態は戻る。

*ワーキングツリー：ユーザーが作業しているディレクトリ領域。
*ステージング：コミット対象のファイルを登録する領域。git addで登録する。

今回は作ったタスクは残しておきたかったので、デフォルトでgit resetし、ワーキングツリーの状態は残し、不要なファイルを削除してからステージングし直すためにステージングを元の状態にしておきます。

コミットを巻き戻したら一応git logで状態をみてみます。
$ git log
commit commitID
Author: author name
Date:   Fri Dec 4 15:06:53 2020 +0900

    ロジック削除

commit commitID
Author: author name
Date:   Fri Dec 4 14:57:10 2020 +0900

    中央揃えにする
コミットが一つ消えました。

手直し

Gemfile.lockとschema.rbの変更を取り消します。
vsコードで取り消しました。
vsコードの左上、

のタブにとび、変更を取り消したいファイルにカーソルを当てて、

をクリックします。

force pushする
$ git add .
$ git commit -m"タスクの追加"
$ git -f push origin <作業ブランチ名>
-fがforce pushするときのオプションです。
なぜforce pushするかというと、リモートには先ほどローカルでresetしたcommitが残っているからです。リモートとローカルに差異があるので、そこをforce pushで強制的に上書きしてしまいます。
こうすることで、不要なファイルを含んだコミットが消えて、不要なファイルを除いたコミットが記録されます。

PR出したローカルブランチがすでにないとき

pushした後、早々にローカルブランチ消してしまったといった場合は、
PRをローカルに落として、作業ブランチに移動してからログの確認・・・という手順を踏めばOkです。
git fetch origin pull/{PR番号}/head:{branch名}
git checkout {branch名}

参考

https://qiita.com/yukibe/items/3d25a8de645432519143

を参考にさせていただきました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T15:07:53+09:00

初心者がしっかりと理解できるようにGitのブランチを説明する

前回はリモートリポジトリにローカルリポジトリの内容をpushするところまでを解説しました。
今回はいよいよ、ブランチについて解説していきます！

前回までの知識がある前提で話を進めますので、まだこれらを読んでない方は是非読んでください。

・なぜ僕らはGitでバージョン管理をするのか
・Gitを触り始めてからGitHubにpushするまでの流れを誰よりも丁寧に説明する

ここではコミットログの解説をするためにターミナルでログを出力します。めっちゃ見辛いログです。
最後にログを見やすくするためのツールを紹介するので、それまでは耐えてください。

ブランチとは？

ブランチという機能、Gitを触りたての頃は何が何だかよくわからないと思います。
端的に言うと「コミット（セーブポイント）の分岐を作る」機能です。その分岐を「ブランチ」と呼んでいます。
これにより、ブランチAでは機能Aの開発をしブランチBでは機能Bの開発をする、という住み分けが可能になります！

何が嬉しいのかは、これから詳しく説明する中で理解できると思います。

Gitはコミットの履歴を管理している

コミットは上書きされるものでなく、追加されるものです。
その追加の履歴をGitで管理しています。
ブランチを理解するにはまずこの概念を理解する必要があります！！

順に確認していきましょう！

コミットログを確認しよう

空のローカルリポジトリを新しく作ってください。（参考）
そしてファイルを作成し、コミットしてみましょう。
$ mkdir (フォルダ名) // フォルダを新規作成する
$ cd (フォルダ名)    // カレントディレクトリを移動する
$ git init         // カレントディレクトリをGit管理する
$ touch test       // 'test'というファイルを新規作成する
$ git add test     // 'test'をステージする
$ git commit -m 'add test'  // 'add test'というコミットメッセージでコミットする
次に、コミットのログを確認してみましょう！そのコマンドはgit logです。
$ git log

commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563 (HEAD -> master)
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:21:59 2020 +0900

    add test
なんか出てきましたね。これがコミットログ（コミットの履歴）です。

読み方を少し解説します。

コミットにはハッシュと言うものが割り当てられ、ハッシュとコミットは1対1で対応しています。ハッシュでコミットを識別します。先頭7桁で識別できるようです。今回特に重要ではないので、詳しくはググってください。
ログにはそのハッシュと、コミットしたユーザー名・コミットした時間・コミットメッセージが表示されています。
コミットログの説明
commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563 (HEAD -> master) // ()内は後ほど解説します
// 33b53a587aa2d1f4a79d126de8d717e4bd97d563 がハッシュ（先頭の33b53a5だけで識別可能）

Author: gakisan8273  // コミットしたユーザー
Date:   Tue Dec 8 01:21:59 2020 +0900 // コミットした時間

    add test // コミットメッセージ
今は1回のみコミットをしたので、1コミットだけがログに表示されています。
それではtest2ファイルを新規作成しコミットして、ログを見てみましょう！
$ touch test2
$ git add test2
$ git commit -m 'add test2'
$ git log

commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b (HEAD -> master)
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:31:13 2020 +0900

    add test2

commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:21:59 2020 +0900

    add test
ログが増えました！やったね！
最初のコミットは消えていません。コミットは上書きでなく追加されることが分かったかと思います。

コミット時間を見ればわかるように、新しいコミットが上に表示されています。

ここでハッシュの行だけを抜き出して表示してみます。
ログから抜粋
commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b (HEAD -> master) // (HEAD -> master)の位置が移動している！
commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563  // d4de11aをコミットする前はここに(HEAD -> master)があった
d4de11aのコミットをしたら、(HEAD -> master)が33b53a5からd4de11aに移動してます！！

何が起こっているのでしょう？

HEADは最新のコミットを指す

まずHEADから説明しましょう。これは単純に最新のコミットを指しています。
最初のコミットの時点では、当然それが最新のコミットでした。なのでHEADがそれにあたります。
次にtest2を追加するコミットをしたら、最新のコミットは変わりますよね。
なのでログのHEADの位置も移動しています。

次にコミットするとき、33b53a5とd4de11aの間にコミットを追加することはできません。
なぜならば、d4de11aのコミットをした時点で、作業をする場所が最新のd4de11aに移動しているからです。
コミットをすると履歴が追加され、常に最新のコミットを参照することを覚えておいてください。

(HEAD -> master)のHEADは何となく分かったかと思います。じゃあ-> masterって何よ？に答えていきましょう！

コミットログはブランチごとに存在する

ようやく出ました、ブランチという言葉。
ここまでの作業でブランチを作った記憶はありませんよね。しかし、Gitはデフォルトでmasterというブランチを1つだけ作っています。
これがいわゆるブランチの「本流」になります。

ローカルリポジトリにどんなブランチがあるかをgit branchコマンドで確認しましょう。
$ git branch

* master // これがブランチ名 先頭の*は作業ブランチであることを示す
このように表示されましたね？現在はmasterブランチ1つだけがあることが確認できました。
Gitの場合、必ず「作業ブランチ」というものを指定します。その作業ブランチに対してコミットを実行しているのです。
ブランチ名の先頭に*がついているのは、それが作業ブランチであることを示しています。
今はブランチが一つしかないので、自動的にmasterが作業ブランチになっています。

実は、HEADが指しているブランチが作業ブランチになるのです。

(HEAD -> master)はHEADがmasterを指しているので、

作業ブランチはmasterである

ということを表しています！！！！

ブランチを作成してみよう（切ってみよう）

他のブランチがあるとどうなるか、確認してみましょう。
ブランチを作成することを、ブランチを切るといいます。何ででしょうね？

ブランチを切るコマンドは、git branch (ブランチ名)です。
new_branchという名前のブランチを切ってみましょう。
$ git branch new_branch
$ git branch

* master      // 作業ブランチはmasterのまま
  new_branch  // ブランチが作成された！！
この状態でログを見てみると…
$ git log

commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b (HEAD -> master, new_branch) // new_branchが追加された！！！！
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:31:13 2020 +0900

    add test2

commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:21:59 2020 +0900

    add test
d4de11aにnew_branchが追加されました！！
(HEAD -> master, new_branch)の意味を解説しましょう！

作業ブランチはmaster（HEADが指しているから）ですね。そして同じコミットにnew_branchもいるようです。
今はmasterとnew_branchが同じコミットを指している同じ状態であると言えます。

ここでコミットを追加すると違いが見えてきます。

ブランチを切った上でコミットしてみよう

今の作業ブランチはmasterのままです。
add_masterファイルを追加してコミットしてみましょう。
$ touch add_master
$ git add add_master
$ git commit -m 'add_master'
$ git log

commit debb8c883b12488593aed009d897300dc21f70d9 (HEAD -> master) // masterだけコミットが追加された
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 02:08:51 2020 +0900

    add_master

commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b (new_branch) // new_branchは変わってない
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:31:13 2020 +0900

    add test2

commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:21:59 2020 +0900

    add test
お分かりいただけただろうか。
作業ブランチであるmasterはコミットが追加されたが、new_branchはそのままです。

もう少し分かりやすくするため、次は作業ブランチをnew_branchに切り替えてコミットしてみましょう。

作業ブランチを切り替えてみよう

切り替えるコマンドはgit checkout (ブランチ名)です。
そしてadd_new_branchファイルを追加してコミットしてみましょう。
$ git checkout new_branch // 作業ブランチが切り替わる
$ git branch

  master
* new_branch // 作業ブランチが切り替わっている
$ touch add_new_branch
$ git add add_new_branch
$ git commit -m 'add_new_branch'
$ git log

commit 7df16ad90a5112d27bfa3d0e9487fb82591007e4 (HEAD -> new_branch) // d4de11aに追加されたコミット
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 02:14:26 2020 +0900

    add_new_branch

commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b // さっきまでnew_branchがいたコミット
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:31:13 2020 +0900

    add test2

commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
Author: gakisan8273 <mint.daa.a2@gmail.com>
Date:   Tue Dec 8 01:21:59 2020 +0900

    add test
d4de11aに7df16adが追加されたことが分かります。
masterが見当たりませんね？git logだけでは作業ブランチに関するログしか表示してくれません。

コマンドにオプションを足してみましょう。git log --graph --allを実行してください。
--graphはログをグラフで表示するオプション、--allは全てのブランチを表示するオプションです。
$ git log --graph --all // --graph グラフ表示する  --all 

* commit 7df16ad90a5112d27bfa3d0e9487fb82591007e4 (HEAD -> new_branch)
| Author: gakisan8273 <mint.daa.a2@gmail.com>
| Date:   Tue Dec 8 02:14:26 2020 +0900
|
|     add_new_branch
|
| * commit debb8c883b12488593aed009d897300dc21f70d9 (master)
|/  Author: gakisan8273 <mint.daa.a2@gmail.com>
|   Date:   Tue Dec 8 02:08:51 2020 +0900
|
|       add_master
|
* commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b  // このコミットからブランチが分かれている！！
| Author: gakisan8273 <mint.daa.a2@gmail.com>
| Date:   Tue Dec 8 01:31:13 2020 +0900
|
|     add test2
|
* commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
  Author: gakisan8273 <mint.daa.a2@gmail.com>
  Date:   Tue Dec 8 01:21:59 2020 +0900

      add test
左の縦線・斜め線がコミットの流れを表しています。雰囲気を感じ取ってください。

d4de11aを起点にして、masterとnew_branchが分かれていますね！！！
このように木の枝のように分かれるためbranchと呼ばれています。

debb8c8はmasterだけが持つコミット
7df16adはnew_branchだけが持つコミットであることが伺えます。

つまり、ブランチごとにコミットログが存在するということです！

また、HEADがmasterからnew_branchに移っていることが分かります。
作業ブランチを切り替えることは、HEADの位置を切り替えることと同じです。

今はadd_masterファイルはmasterブランチだけが参照でき、add_new_branchファイルはnew_branchブランチだけが参照できることになります。
確認してみましょう。
new_branchが作業ブランチ
$ git branch

  master
* new_branch

$ ls // カレントディレクトリに存在するファイルを表示するコマンド

add_new_branch test           test2 // add_masterはない
masterに作業ブランチを切り替える
$ git checkout master
$ git branch

* master
  new_branch

$ ls

add_master test       test2  // add_new_branchはない
それぞれの作業ブランチでコミットしたものしかないことが分かります。

ブランチを統合しよう

実際にシステムを運用するときは本流であるmasterブランチを参照するでしょう。
new_branchで追加したadd_new_branchファイルをmasterに反映させる必要があります。

そのコマンドが、git merge！！！！
実行してみましょう！！
$ git branch

* master               // masterにブランチを統合したいので、作業ブランチをmasterにする
  new_branch

$ git merge new_branch // 作業ブランチに統合するブランチを指定する
mergeすると、このようにコミットメッセージを入力するためにvimが起動します。
コミットメッセージを変更せずに、:qを入力してエディタを閉じましょう。
merge後にコミットメッセージを入力する
  1 Merge branch 'new_branch'  // ここがコミットメッセージ
  2 # Please enter a commit message to explain why this merge is necessary,
  3 # especially if it merges an updated upstream into a topic branch.
  4 #
  5 # Lines starting with '#' will be ignored, and an empty message aborts
  6 # the commit.
~
これでmasterにnew_branchが統合されました。このことをマージと呼びます。
masterに何のファイルがあるか見てみましょう。
$ git branch

* master
  new_branch

$ ls

add_master     add_new_branch test           test2  // add_master, add_new_branch 両方ある！！
masterで追加したadd_masterとnew_branchで追加したadd_new_branchの両方がmasterにあることが確認できます！
ブランチがマージ（統合）された、ということですね。

コミットログを見てみましょう。
$ git log --graph --all

*   commit 4010613273f3d1539a346f34562730e4510e9704 (HEAD -> master)
|\  Merge: debb8c8 7df16ad
| | Author: gakisan8273 <mint.daa.a2@gmail.com>
| | Date:   Tue Dec 8 12:14:33 2020 +0900
| |
| |     Merge branch 'new_branch'
| |
| * commit 7df16ad90a5112d27bfa3d0e9487fb82591007e4 (new_branch)
| | Author: gakisan8273 <mint.daa.a2@gmail.com>
| | Date:   Tue Dec 8 02:14:26 2020 +0900
| |
| |     add_new_branch
| |
* | commit debb8c883b12488593aed009d897300dc21f70d9
|/  Author: gakisan8273 <mint.daa.a2@gmail.com>
|   Date:   Tue Dec 8 02:08:51 2020 +0900
|
|       add_master
|
* commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b
| Author: gakisan8273 <mint.daa.a2@gmail.com>
| Date:   Tue Dec 8 01:31:13 2020 +0900
|
|     add test2
|
* commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
  Author: gakisan8273 <mint.daa.a2@gmail.com>
  Date:   Tue Dec 8 01:21:59 2020 +0900

      add test
masterでマージをしたので、マージコミットというものが最新のコミット(4010613)として生まれます。
左の縦線が7df16ad（new_branchが参照してるコミット）から4010613（masterの最新コミット）に伸び、統合されています。

・・・だから何？なんでブランチが必要なの？masterだけで作業すればマージする必要もなくていいじゃん！

と、思いますよね。ブランチがあると何が嬉しいのかを説明していきましょう！

ブランチの嬉しさ

ブランチにより別機能開発を同時並行しやすくなります！！！！

ブランチがmaster一つしかない場合を想像してください。

あなたはmasterブランチで機能Aの開発をしています。いい感じに実装を進めていると上司から「急ぎで機能Bを実装してくれ！」と依頼が来ました。
機能Aの実装を中断するため、キリのいいところでコミットしました。機能Aは少しバグがあるものの、動いています。
そして機能Bの実装を開始します。

機能Bの実装を無事終えてユーザーが使用を始めています。機能Aの実装に戻ることにしました。
ところが！機能Aが全く動作しなくなっていました！！！原因は機能Bの実装であることは明らかです。
修正するには機能Bで実装したところに手を入れるしかありません。
しかしそれをすると、今ユーザーが使っている機能Bが動かなくなってしまうかもしれません…困った…どうしよう…

機能ごとにブランチを分けた場合を考えてみましょう。

あなたは機能Aの開発をするため、masterブランチからfunction_aブランチを切り、そこで実装を進めていました。
上司から「急ぎで機能Bを実装してくれ！」と依頼が来ました。
機能Aの実装を中断するため、function_aブランチでキリのいいところでコミットしました。機能Aは少しバグがあるものの、動いています。
そして機能Bの実装を開始するため、masterブランチからfunction_bブランチを切りました。

機能Bの実装を無事終えて、function_bをmasterブランチにマージしました。ユーザーが使用を始めています。
機能Aの実装に戻るため、function_aブランチに切り替えます。
function_aとfunction_bは互いに独立しているので、機能Aは中断した時と変わりありません。
そのままfunction_aブランチで機能Aの実装を終え、masterにマージして無事リリースできました。

どうでしょう。嬉しさが少しは分かったのではないでしょうか？

とはいえ…ブランチは実際に開発で使わなければその恩恵が理解しにくいと思います！！！！
また一人で開発している分にはブランチを切らなくてもあまり不自由ありません！！！！（個人差があります）

しかしぜひ！！ブランチを使ってみて何ができるかを体感して欲しい！！！お願いします！！

コミットログって見にくくない？？？

さて皆さん、ここまでコミットログをターミナルで表示して来たかと思います。
クッソ見辛いですよね？？？だから解説もしにくいし…

もっと見やすくする方法があるので、それを紹介します。

VSCodeの拡張機能「Git Graph」を使おう！！！

まずVSCodeというエディタをインストールしてください。方法はググってください。
そしたらVSCodeを起動し、VSCode内の拡張機能でgit graphと検索します。出ます。
インストールしましょう。

ソース管理タブのGitGraphっぽい右側のアイコンをクリックすると、ウィンドウにコミットログが表示されます。

この見やすさの違い、Git Graphを使わない理由がない！
Git Graphでもハッシュやコミットメッセージが見れるのは当然で、それに加えてコミット内容などまで見ることができます。
ターミナルの上位互換と考えて差し支えないです。
$ git log --graph --all

*   commit 4010613273f3d1539a346f34562730e4510e9704 (HEAD -> master)
|\  Merge: debb8c8 7df16ad
| | Author: gakisan8273 <mint.daa.a2@gmail.com>
| | Date:   Tue Dec 8 12:14:33 2020 +0900
| |
| |     Merge branch 'new_branch'
| |
| * commit 7df16ad90a5112d27bfa3d0e9487fb82591007e4 (new_branch)
| | Author: gakisan8273 <mint.daa.a2@gmail.com>
| | Date:   Tue Dec 8 02:14:26 2020 +0900
| |
| |     add_new_branch
| |
* | commit debb8c883b12488593aed009d897300dc21f70d9
|/  Author: gakisan8273 <mint.daa.a2@gmail.com>
|   Date:   Tue Dec 8 02:08:51 2020 +0900
|
|       add_master
|
* commit d4de11a70e45c9d7c4481fd3b1aa1d10445d839b
| Author: gakisan8273 <mint.daa.a2@gmail.com>
| Date:   Tue Dec 8 01:31:13 2020 +0900
|
|     add test2
|
* commit 33b53a587aa2d1f4a79d126de8d717e4bd97d563
  Author: gakisan8273 <mint.daa.a2@gmail.com>
  Date:   Tue Dec 8 01:21:59 2020 +0900

      add test
便利ツールの落とし穴

Git Graphは様々な機能を持っています。
マウスポチーでコミットの取り消しができたり、コミットの移動ができたりもします。
しかし！これを読んでいる皆さんはまだその機能を使わないでください！！

結局はどんな操作でも裏でGit Graphがコマンドを叩いているので、「この操作でどんなコマンドが実行されるのか」を理解していないと思わぬ事故に繋がります。

まずターミナルでどう操作すればいいかを理解してから、便利なツールを使いましょう！
本記事でクッソ見辛いgit logをあえて使ったものその理由からです。

さいごに

ブランチの説明、プログラミング初学者に分かりやすく説明するのはめっちゃ難しいです。
僕も学びはじめの頃、色々な解説記事を見ましたが何が何だか分かりませんでした…
しかし、実際にブランチを切って触っていくうちに理解できました。

例によってこの記事は初学者向けに書いているので、正確でない部分もあります。
しかし最初はこの理解で十分ですので、気になったらその都度精査してみてください。

この記事がしっかりと解説してくれているので、より細かく知りたい方は是非参照してみてください。
図解！ Gitのブランチ・ツリーをちゃんと読む

特にこのブランチという機能は実際に触らなければ、そして複数人開発をしなければ、必要性が分かりにくいものだと思います。
初学者にとっては非常にとっつきにくいものでしょう。

とりあえず何か開発するときは、機能ごとにブランチを切る習慣をつけておいて欲しい！
そうしてればそのうちコンフリクトが起こって解消方法に悩んだり、rebaseしたりcherry-pickしたくなる時が来るでしょう。
それらを一つ一つ乗り越えて徐々に理解が深まっていくものです。

さあ自分のリポジトリにブランチを作ってみよう！！！

よかったらTwitterもフォローしてね。怪しいアカウントじゃないよ。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T13:14:07+09:00

個人的に便利だと思ったgitコマンド集

背景

完全独学で触ってきたgitですが、流石に体系的に勉強した方がいいだろうと思って、勉強しました。
そこで学んだ便利なコマンドを記載していきます。なお、gitを使っている方々にとっては当たり前の内容となっております。
完全に個人的な備忘録です。

ちなみに勉強した本はGitHub実践入門です。まだ読み途中なので、読み終えたら追記もしくは別記事で投稿します。

コマンド集

コミットメッセージ

いきなりコマンドではなくてすみません笑。コミットメッセージには、フォーマットがあるらしく、それに則った方が今後便利だなと思いました。
1行目: コミット内容のようやく
2行目: 空白行
3行目以降: コミット内容の詳細内容や背景など

過去のコミットメッセージ1行目のみ表示
git log --pretty=short
ファイルの差分表示
git log -p [file name]
ワークツリーとステージ領域の差分確認
git diff
ワークツリーと最新コミット領域の差分確認

変更したファイルを全てステージ領域に追加すると、 git diff では何も差分が表示されなくなる。
最新コミットと比較したい時には、下記のようなコマンドを実行する。
git diff head

ブランチの流れを視覚的に表示
git log --graph
新しいブランチを作成し、そちらに切り替える
git checkout -b [branch name]
現在のリポジトリでの作業ログ
git reflog
ブランチを戻す
git reset --hard [hash value]
＊ハッシュ値については、 git log --graph や git reflog などを使って確認すること
＊戻した後に、 git reflog などを使ってハッシュ値を取得できれば、再度戻す前の状態にも戻れる。

ブランチのマージ

マージ先のブランチ(例えば、masterブランチ)にいる状態で実行する。
git merge [branch name]
＊コンフリクトが起きたら、対象ファイルを開き、修正して再度ステージング及びコミットする

直前のコミットメッセージを修正
git commit --amend
複数コミットをまとめる

直前2つのコミットをまとめたい場合
git rebase -i head-2
＊ここのheadは最新コミットを指す。
pick [hash value] [commit message1] # 最新の1つ手前のコミット
pick [hash value] [commit message2] # 最新コミット
最新コミットの方のpickをfixupに書き換えることで、
1つ手前のコミットにまとめることができる。
コミット後に見つけた軽微なバグ修正などで使う。
なお、改竄方法はgit rebaseコマンド実行時に表示されているので、そちらを読むことでより理解できるだろう。

リモートリポジトリの登録
git remote add origin git@github.com:hoge/huga.git
＊originという識別子は今後、git@~として認識されるようになる。
＊なお、push時に-uオプションを付けることで上流ブランチとして登録させることができる
例、 git push -u origin master
ちなみに上の例は、origin(リモートリポジトリ)のmasterブランチにpushしているという意味。
masterの部分を別のブランチ名にすると、そのブランチにpushされる。
そのブランチが存在しない場合は、作成される。

リモートリポジトリを含めたブランチの確認
git branch -a
master remotes/origin/master リポジトリにもよるが、おそらく上記のように表示される。上記では、ローカルリポジトリのmasterブランチにいて、リモートリポジトリにはmasterブランチのみが存在しているという意味。 remotesが(ローカルではなく)リモートリポジトリを指しており、originは先ほど指定した特定のリモートリポジトリを指している。

リモートリポジトリのブランチをチェックアウトする

リモートリポジトリにあるブランチを元に手元のローカルリポジトリにブランチを作成する
git branch -b develop origin/develop
＊リモートリポジトリにdevelopブランチがある前提

最新のリモートリポジトリの情報をローカルリポジトリに反映

例えば、別の開発者によってリモートリポジトリに変更が生じた場合、下記コマンドでそれをローカルリポジトリにも反映させる。
git pull
# もしくは
git pull origin develop # originのdevelopの変更をローカルに反映
リモートリポジトリのブランチが変更されていた場合、このコマンドでローカルリポジトリにもその変更が反映される。
なお、変更がかぶっていた場合、コンフリクトが発生する。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-08T11:23:33+09:00

ファイルシステムをCase-sensitiveに設定しておこう for Mac

前置き

この記事は 2020 年の RevComm アドベントカレンダー 15 日目の記事です。 14 日目は
@tatakahashi35 さんの「 RevComm の裏側で動くアルゴリズム [二分探索編] 」でした。

こんにちは、 RevComm のエンジニアの持田です。 MiiTelに続く、第二弾プロダクトの開発を担当し、プロジェクトマネージャーも兼任しています。
今回は、Macで作業していて少しトラブったことがあったので、反省のために具体的な事象と解決方法をお話したいと思います。
なお、 Gitを用いた開発をしている方であれば誰でも起こりうる ので、一読いただくとのちのち助けになるかと思います。

発生したトラブル

とあるフロントエンドの改修で、ローカルのgitリポジトリ以下に存在する、setting.js ¹ というファイルを、Setting.js ¹ にリネームしました。
この変更がgitに検知されず、コミットに含まれなかったことが原因²で、開発環境でNo such file or directory エラーが発生しました。

どうやらMacでは デフォルトで大文字小文字を区別しない ファイルシステムが設定されていたようでした。
再発を防ぐため、大文字小文字を区別する開発用のボリュームを作成することにしました。

大文字/小文字を区別するボリュームの作成方法

Command + Spaceで「ディスクユーティリティ」と入力して、ディスクユーティリティを起動します。その後、ボリュームを追加します。

フォーマットで、APFS (大文字/小文字を区別) を選択します。暗号化するかどうかは用途に合わせてください。

ボリュームが作成されると、マウントポイントが表示されます。こちらのディレクトリ以下に開発ディレクトリを置くと良いでしょう。

確認方法

Case-sensitiveに設定できている場合は、下記のように大文字で始まる「Test」と小文字で始まる「test」の両方のファイルを作成できます。
mochida@mbp ~             % cd /Volumes/casesensetive
mochida@mbp casesensetive % touch test
mochida@mbp casesensetive % touch Test
mochida@mbp casesensetive % ls
Test    test
また、ディスクユーティリティでも、「大文字/小文字を区別」という記載がされるので、こちらでも確認できます。

他の方法

後で調べたところ、Gitでファイル名の大文字・小文字の変更を検知するようにするという記事でも、本事象に関しては解決できそうでした。

あえてファイルシステムを変更するメリットとしては、
サーバーとして多々利用される、Amazon Linux 2 などではデフォルトで大文字/小文字を区別するようになっているので、少し手間はかかりますが開発端末も合わせておくと良いかもしれません。

最後に

明日は @shuheikatoinfo さんの「音声合成・激動の10年を振り返る」です。

実際とは異なる、わかりやすい名前を使っています。 ↩

そもそも開発環境にデプロイするまで気がつかなった原因として付け加えるなら、差分のチェックが甘かったことと、build時のエラー検知が適切に設定されていなかったことも挙げられます。 ↩

　 Tweet
Qiitaで続きを読む

20201208のGitに関する記事は12件です。

GitGuardianから警告がきて焦った話

はじめに

GitGuardianとは

参考

GitGuardianから警告メールがきて焦った話

はじめに

GitGuardianとは

最後に

参考

用語メモ（バージョン管理関連など）

用語メモ

今日の名言

Git/GitHubの初期操作に触れてみた(@Python/Django)

はじめに

GitHubの初期操作

まとめ

Git/GitHubに触れてみた(@Python/Django)

はじめに

GitHubの初期操作

まとめ

gitでプッシュする前に確認すべきこと

この記事を書こうと思ったきっかけ

対象読者

チェック項目

大前提

git addする前

git add後

git commit後

問題がなければ'git pull origin master'を行う。（超重要！！）

git push後

その他

Git/GitHubの初期設定について簡潔に触れてみた

はじめに

初期設定

まとめ

プルリクエストを出すときに意識すること

PRを出す前に確認すること

書くべきこと

pushした一部ファイルの取り消し方

経緯

まずログの確認

コミット巻き戻し

手直し

force pushする

PR出したローカルブランチがすでにないとき

参考

初心者がしっかりと理解できるようにGitのブランチを説明する

ブランチとは？

Gitはコミットの履歴を管理している

コミットログを確認しよう

HEADは最新のコミットを指す

コミットログはブランチごとに存在する

ブランチを作成してみよう（切ってみよう）

ブランチを切った上でコミットしてみよう

作業ブランチを切り替えてみよう

ブランチを統合しよう

ブランチの嬉しさ

コミットログって見にくくない？？？

VSCodeの拡張機能「Git Graph」を使おう！！！

便利ツールの落とし穴

さいごに

個人的に便利だと思ったgitコマンド集

背景

コマンド集

コミットメッセージ

過去のコミットメッセージ1行目のみ表示

ファイルの差分表示

ワークツリーとステージ領域の差分確認

ワークツリーと最新コミット領域の差分確認

ブランチの流れを視覚的に表示

新しいブランチを作成し、そちらに切り替える

現在のリポジトリでの作業ログ

ブランチを戻す

ブランチのマージ

直前のコミットメッセージを修正

複数コミットをまとめる

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

リモートリポジトリを含めたブランチの確認

リモートリポジトリのブランチをチェックアウトする