どうも。つじけ（tsujikenzo）です。今日は 「Githubでチーム開発を楽にしよう」 を、前半、後半でお送りします。今日は、後半戦です。
前回のおさらい
前回は、Githubアシスタントのインストールなどを行いました。
mainブランチからソースコードをpullしましたね。
今回は、実際にソースコードを書く準備をしていきます。
今日のアジェンダ
- Branchを切ろう
- PUSHしてみよう
- プルリクしてみよう
- Githubを使う理由
Branchを切ろう
自分のコードを書く準備をします。
いまは、ブランチ名[main]で作業（PULLしただけですが）をしています。
mainブランチは、チーム全員が作り上げるメインのソースコードになります。
※正確にいえば、[main]はブランチではなく、木の幹になるので、[Trunk]と呼んだほうが正しいですが、なぜかデフォルトの作業場所もブランチと呼んでいます。
なので、mainブランチは、全員のコードを合算した作業場、個人ブランチは、自分専用の作業場、とイメージしてください。
ブランチを切る
ブランチを作成することを、「ブランチを切る」と言います。
ブランチの▼をクリックして、[Create New branch]をクリックします。 
お好きな名前（分かりやすく自分の名前がいいでしょう）を付けて、「Create」をクリックします。 
実行ログにこのように表示されたら成功です。 
自分のブランチ名が正しく表示されていると思います。 
この状態で、コードを書いていきましょう。
PUSHしてみよう
mainブランチから、自分ブランチを切って、作業を始めました。
自分ブランチの最新状態を、Github上にアップロードして、保存しておきましょう。
Githubにアップロードすることを、「PUSH」と言います。
PUSHはとてもかんたんです。
リポジトリ名とブランチ名を確認して、[↑]をクリックします。 
ソースコードの差分が表示されるので、確認して、コメントを入力して、[Push]をクリックします。 
実行ログに「サクセスしたよ」と表示されれば成功です。 
Pull requestsしてみよう
さいごに、自分ブランチで作業した内容を、[main]ブランチにマージしてもらいます。
マージとは、あなたが作業した内容を、メインのソースコードに統合するという意味です。
マージするのは、管理者です。
なので、管理者に「マージしてください！」とお願いをすることを「Pull request（以降、プルリク）」と言います。
プルリクを作成するのは、ブラウザからです。
まず、Githubのリポジトリにアクセスして、[Pull request]をクリックします。 
[New pull requests]をクリックします。 
手順は以下の3つです。
- ブランチのbase（矢印ひだり）が[main]になっているか確認する
- ブランチのcompareをクリックして、プルダウンから「自分ブランチ」を選択する
- Create pull requestsをクリックする
次に、Reviewersで、管理者を追加します。 
タイトルやコメントを入力して（厳密なルールはありません。伝えたいことがあれば入力してください）、最後に[Create pull requests]をクリックします。 
プルリクが成功しました。あとは、管理者からの返事を待ちましょう。 
プルリクが送信されると、Slackに通知が飛ぶように連携していますので、とくに連絡は不要です。 
以上で、操作は終わりです。お疲れ様でした。
Githubを使う理由
スクリプトエディタにソースコードは保存されてるのに、なぜGithubにアップロードするのか？という疑問があるかもしれません。
Githubにアップロードするメリットはさまざまです。
スクリプトエディタ上での共同作業は危ない
スクリプトエディタを同時編集すると、保存のタイミング、リロードのタイミングによって、他のメンバーのコードを削除してしまう可能性があります。
ちゃんと気を付けて上書き保存、リロードを行えば問題ないのですが、人間なので、手順を忘れたりします。
このおかげで、「せっかく書いたコードが消えた」なんてことも数多く経験してきました。
ソースコードの保管場所をGithubにすれば、そのような問題はおきませんし、別途自分用のスクリプトエディタを用意して作業する必要もありません。（コンテナバインドスクリプトなどはコードを書き換える手間が発生しますよね）
作業中のコードをブラウザで閲覧・編集できる
Githubは、ブラウザからも確認できます。
リポジトリを選択することはもちろん、ブランチも選択できます。 
実際に、シンタックスハイライトが効いたコードを参照できますし、なんと、ブラウザで編集もできます。 
ここだけの話、わたしはGithubになれていない初心者のとき、ソースコードを書いたら、ブラウザにコピペして保存してました・・・。
現在のバージョンを保存して、挑戦的なブランチにトライできる
これが、いちばんのメリットですが、GASのスクリプトエディタでは「バージョンの管理」ができません。
このバージョンで、いったん保存しておきたい。コードを書き進めたけど、ある時点に遡りたい、と思うことはありますよね。
そんな、スクリプトファイルのバージョンの管理を、Githubは可能にします。
今は個人ブランチを作成しただけですが、個人ブランチから、さらに「個人実験ブランチ」を切ってもかまいませんし、いつでもブランチを廃棄できます。
バージョン管理したいのはソースコードだけではない
この、便利なバージョン管理ツール「Github」が、いまはデザインや、文書管理に使われています。
イラストレーターのファイルや、Wordファイルはもちろんですし、映像を編集したmp4ファイルや、ありとあらゆるものがGithubでバージョン管理されています。
さらに、現在の課題を共有するIssuesなど、課題解決のコミュニケーションツールとして、魅力的な機能が満載です。
徐々に慣れていきましょう。
まとめ
以上で、「Githubでチーム開発を楽にしよう」をお届けしました。
さまざまな企業が、Githubを活用する時代になりました。
つまり、Githubでリポジトリを作成することは、あなたの仕事っぷりを評価してもらうポートフォリオにもなるのです。
また、「あなたの労働市場価値」をはかるとき、Githubの上級者は世に数多く存在しますが、「貿易業界でGithubを使いこなしてる人材」なら、ライバルも少ないかもしれません。
「北海道で食品関係でGithubを使いこなしてる人材」なら、さらにライバルが少ないかもしれません。
スキルは掛け算です。Githubは、働く上でかならず役に立つ武器になるでしょう。
