ブラックペッパー地獄好き【TECH::EXPERT】

Git/GitHub TECH::EXPERT プログラミング 応用カリキュラム編

【本日のメニュー】
・コードレビュー依頼
・LGTM
・マージ
・マージしたブランチを削除
・プル
・git clone
・GitHub flow
・デプロイ時におけるGitHubの役割
・Git/GitHubのトラブルシューティング
・理解度テストGit編

【コードレビュー依頼】
Slack等のコミュニケーションツールでリポジトリURLを送信するほか、プルリクエストの際にメンションをつけるなど方法がある。
これはチームで統一した方が良さそう。

【LGTM】
Looks good to meの略で、「コードに問題がないのでマージしていいよ!」という意味らしい。
ありがたや〜!

【マージ】
マージ(merge)は統合するという意味です。機能実装のために作成したブランチを、masterブランチに統合する作業。
ファイルがバッティングした時なんかは、両者のいいとこ取りとか、比較して良いコードを反映とかありますよねー。

【マージしたブランチを削除】
これをすることでひとつのパラレルワールドが削除されるそうです。
問題ないソースコードが納品されたから案件が1つクローズした感覚に近いっすね。

【プル】
リモートリポジトリの変更をローカルリポジトリに取り込む操作。
逆も然りですが、リモートの方でマージされたが、ローカル側がそのままなのでプルで更新します。

【git clone】
課題のDLなどにも使われたこのコマンドですが、GitHubでグループワークする時は

Git clone → push&pullでリクエスト的なものを送る → リポジトリ管理者がCollaboratorsに追加(リクエストOK)的なことをすると共同作業が始まるよう。

【GitHub flow】
GitHub自体が推奨する開発フロー

・masterブランチのものは何であれデプロイ可能である
・新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する(例:  new-oauth2-scopes)
・作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
・フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、プルリクエストを作成する
・他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる
・マージをしてmasterへpushしたら、直ちにデプロイをする

https://gist.github.com/Gab-km/3705015

【デプロイ時におけるGitHubの役割】
アプリケーションをサーバー上で利用可能な状態にすること。
Ingressに一時期はまっていましたが私の知ってるデプロイと違う。
ブラウザで表示してみてもらえるようにするような行為のことをデプロイというらしいです。
HTMLとCSSの静的なサイトだと、FTPでファイルをサーバーにあげると、特定のURLで見れるようになりますが、それがGitHubを絡めるとデプロイってことにしとこう。

ブランチを作成 > コード変更修正 > 動作確認 > マージ > サーバー側にpullデプロイ
このような流れでアップすると稼働中のサービスを長時間止めること無くアップデートすることが可能らしい。

【Git/GitHubのトラブルシューティング】
・同じファイルを別の人が既に修正していてマージができない
>このような事象をコンフリクト(競合)と言う

擬似的にコンフリクトを起こして対処練習する方法

ブランチを2件つくる

「test.rb」を修正

ブランチAで「test.rb」コミット

「test.rb」を修正

ブランチBで「test.rb」コミット

上記の流れで再現できる。競合なのにひとりでもできるもん。(哲学)

【理解度テストGit編】
42点!所々合ってるけど、解釈が混ざってたり
意味が同じこと2行書いてたりしてました。
全部埋めたには埋めたのは満足。
もうちょっと意識がはっきりしてる時(眠くない時)に再戦しましす。