[Git/GitHub2]今日の学習アウトプット！
GitHub Desktop操作の整理
publish repository：リモートリポジトリ作成+push(commitの反映)
push origin：ローカルの変更をリモートに反映
publish branch：トピックブランチの作成+push
pull request：commit履歴を残す+コメント機能
リ：merge pull request→Confirm merge：リモートのmasterブランチへトピックブランチを統合
Fech origin→pull origin：リモートリポジトリの変更をローカルに反映
(pull origin = fech + pull)
GitHubにおいて、1つのファイルで、どうやって共同作業するのか。
それは、ブランチを切ることで可能になる。
ブランチとは、変更の流れ、≒commitの連なりのこと。
本流のブランチをmasterブランチ、
派生させたブランチをトピックブランチという。
ブランチを切る、とはmasterから枝を派生させること。
こうして切り出すことで同時作業を可能にする。
また、切り分けているため不具合が出ても影響が最小限
といったメリットがある。
ブランチを切る方法は、
GitHub Desktopで、Current BranchからNew Branchを選択。
ブランチ名を入力し、Create Branch。
作成したブランチをリモートレポジトリに反映するには、
Publish Branchをクリックする。
ブランチで編集・実装作業後、
変更をcommitし、masterブランチに反映するには
プルリクエストというものを利用する。
これは、commit履歴を残すことに加え、
コメントもできるGitHubの機能。
分岐した枝であるトピックブランチをmasterに統合する前に、
コードに問題がないかチェックしてもらうことができる。
実際のやり方は、
GitHub DesktopからCreate Pull Requestをクリックすると、
プルリクエスト作成画面に遷移する。
ここで必要事項を記入後、Create Pull Requestをクリックして作成する。
ここのでのポイントは、以下２つ。
・何を、何のために実装したのか記述
・マークダウン記法を活用する
要は、コードチェックをしてもらう人(レビュアー）に、
作業内容をわかりやすく伝えること。
コントローラー実装のために、○○コントローラーを作成した。
など、何をとなぜがあるとレビュアーもレビューがしやすくなる。
また、マークダウン記法で見出しなどを用いて
見やすいコメントを追加するとよい。
このコードレビュー依頼方法は、
メンションで通知するか、
GitHub以外の連絡ツールでURLを共有する方法がある。
レビュアーは、URLのFiles changesから変更一覧を確認できる。
また、特定ファイルの特定行にコメントすることもできる。
レビュアーから、修正依頼をもらった場合は
修正依頼ごとにcommitするとよい。
まとめてpush後、
確認したという意味も含め、コメントに返信するとベスト。
最終的にLGTM(コードに問題はないよ！)をもらえたら、
いよいよmasterにトピックを統合する。
方法は、プルリクエスト画面下部の
Marge pull requestをクリックするとConfirm mergeに変わるので
再度クリックする。
統合後は、トピックブランチは不要になるため
Delete branchで削除しておく。
統合は、リモートポジトリで行ったので
今度はこれをローカルにも反映させる。
これをpullという。
pullの方法は、
GitHub DesktopでCurrent BranchをMasterに変更して
Fetch originをクリック。
差分があるとpullしますか？、と出てくるので
Pull originをクリックしてpullする。
またローカルからは、トピックブランチが削除されていないので
別途削除する。
これについては、こちらで。
ちなみにcloneとpullの違いは、
pullは、リモートとローカルがそもそも紐付いていて、
リモートの状態にローカルを同期させるが、
cloneは、そもそも紐づくローカルが存在しない。
リモートからローカルを作成する。
また、他人のリモートからcloneした場合、
権限を追加してもらわないとpushできない。
***
Gitで共同編集ができるといったものの、
コンフリクトは0にはならない。
ファイルの同時編集により、辻褄があわなくなってしまったファイルは
marge操作ができなくなる。
その場合の解決方法は、
mergeをする画面(pull request中部くらい)から、
Resolve conflictsを選択し、コード修正する。(下図の右上！)
コードを修正したら、右上のMark as resolvedを選択する。
これをファイル毎に行う。
全ファイルの修正ができたら、ページ右上にCommit mergeが出現。
クリックすることで、mergeができるようになる！
エラー関連でいうと、
他にはブランチの切り替え忘れ、pushミス、commitミスなども
よくおこるエラーである。
順にまとめる。
まずmasterブランチで作業してしまった場合。
Current Branchから、New Branchで
移したいブランチを作成して、Current Branch。
すると下記２つの選択肢が表示される。
上を選ぶと、変更した内容は一旦保留。
stashという状態になる。
そのため、新しく作成したブランチにはコードが引き継がれず、
1からコードを記述する。
下を選ぶと、masterブランチで作業した変更分を
ごっそり新しいブランチへ引っ越せる。
ブランチ作成忘れの場合、下を選ぶとよい。
上はどんなときに使うかというと、
一時的に今のブランチでの作業から退避したい場合などに使える。
stashになった変更点は、変更作業をしていたブランチの
staches Chang(画像の青い部分)というところから
もとに戻したり(Restore)、削除したり(Discard)できる。
次にpushしたくないのに、しちゃった場合。
revertという機能で、commitを打ち消せる。
commitを削除するのではなく、逆の変更を追加することで打ち消す。
やり方は、
GitHub DesktopのHistoryから、該当commitを右クリック。
Revert Changes in Commitを選んで、(下図)
そのあとにpush origin。
最後に、commitを取り消したい場合。
これはpushしてしまった後より操作が楽で
commitするエリアのUndoをクリックするだけ。(画像右下)
これで、commitする前の状態に戻る。
個人的にポイントに感じたのは、下記2点。
・コンフリクトを解消する際は、編集者と相談する。独断でしない。
・エラーでパニックになって、やみくもにコマンドを試すと取り返しのつかない状態になる。
今回のように仮アプリを作成して、試してみるのも1つの手。