Git/ GitHub の使い方の基礎

バージョン管理システムの Git および Git を利用したソフトウェア開発プラットフォームである GitHub を使い始めてみたので，その模様を記録する．

使用しているOSはWindows10．

Git / GitHub の導入

Git のインストール

まず，コマンドライン版のGitをインストールした．

ただ，GitHub を利用するだけならば不要なようなのだが，後々色々なアプリと連携を取っていく上で必要そうなので念のため．

公式サイトはこちら

“Git” https://git-scm.com/

本サイトより最新版であったver.2.29.1をダウンロードした．

インストール時に多数のオプションが出てきたが，基本的にデフォルトのままで済ませてしまった．

唯一，デフォルトエディタの設定のみは，今用いているAtomを選択した．

GitHub Desktop のインストール

まず，GitHubのアカウント作成を公式サイトよりする．

“GitHub” https://github.com/

次に GitHub Desktop のインストールをする．

“GitHub Desktop” https://desktop.github.com/

ローカルリポジトリ

Git では，ディレクトリをリポジトリ（repository）化すると，.gitディレクトリが生成され，ここに変更履歴などが格納される．

自分のPCのようなローカルな環境下にあるリポジトリがローカルリポジトリ，GitHubのようなネットワーク上にあるのがリモートリポジトリである．

まず，ローカルリポジトリを試しに作って，色々いじってみる．

新規ローカルリポジトリの作成

GitHub Desktop で新規ローカルレポジトリを作成するには，メニューバーのFile>New repositoryまたはCtrl+Nである．

Create a New repository ダイアログが現れるので，Name，Description(レポジトリの説明)，pathを入力すれば作成できる．

作業レポジトリは，メニューバーの下のCurrent repositoryから操作可能である．

なお，既に存在するローカルリポジトリを新たにGitHub Desktopに取り込むには，メニューバーのFile>Add local repositoryまたはCtrl+Oで可能である．

クローン

リモートリポジトリをコピーし，ローカルリポジトリを作成することもできる．この操作をクローンという．

クローンはパブリックレポジトリならば，誰でもできる．

GitHubのリモートリポジトリのページにアクセスし，Code>Open with GitHub Desktopで，GitHub DesktopよりCleate a repositoryダイアログが表示されるので，パスなどを指定して，cloneを押せば作成される．

コミット

作成したローカルレポジトリ内のファイルを適当に変更してみる．

今回，”test1.txt”の内容を変更し，”test2.txt”をファイルごと削除，”test3.txt”を新たに作成してみた．

このとき，GitHub Desktopにはこのように表示される．

“test1.txt”の内容の変更前が赤で，変更後が緑で強調表示されている．

また，”test1.txt”に変更が加えられたことを示す四角に丸のマーク，”test2.txt”が削除されたことを示す四角にーのマーク，”test3.txt”が新規作成されたことを示す四角に+のマークがついている．

今，3つのファイル全ての変更に対して，チェックがついている．
この状態がファイルがステージングエリアに置かれている状態である．

ステージングエリアの変更をリポジトリに記録することをコミットすると言う．

コミットは，Changesの下の部分から，コミットメッセージを入力し，”Commit to main”を押すことでできる．
コミットメッセージはタイトルと説明が入力できるが，説明は任意である．

コミットするファイルの選択は，ステージングのチェックで可能である．

リバート

コミットの履歴はHistoryタブから確認可能である．

コミットを取り消したいとき，プッシュなどの操作がされていない直前のコミットならば，”Undo”を押すことで取り消し可能である．
これは履歴にも残らない．

一方，”Undo”で取り消せないコミット，またはコミットの取り消しを履歴に残したい場合は，リバートをする．

リバートとは，コミットの変更を打ち消す変更をするコミットのことである．

GitHub Desktopでは，Historyタブの最新の履歴を右クリック>Revert this commitより，リバートできる．

履歴にも，リバートが記録として残ることが確認できる．
また，リバートされた内容は自動でファイルに反映されて保存されるようだ．

最新以外の履歴に戻りたい場合は，リバートを繰り返せばよい．

また，リバートを取り消したい時も，リバートをリバートすることが可能だし，直前なら”Undo”もできる．

ちなみに，まだコミットしてないが保存したファイルをコミットしたときの状態に戻したい場合は，changesタブ上で右クリック>Discard changesをすればよい．

ローカルリポジトリの削除

GitHub Desktop では，削除したいレポジトリ上で右クリック>RemoveでＲemove repositoryダイアログが表示される．

ここで，Ａlso move this repository to Recycle Bin にチェックを入れると，当該ディレクトリのフォルダごと削除される．

チェックを入れないと，GitHub Desktopのレポジトリのリストには表示されなくなるが，.gitディレクトリを含めたフォルダは保持される．

いずれの場合も，リモートレポジトリは削除されない．

リモートリポジトリ

リモートリポジトリの作成

作成したローカルリポジトリからリモートリポジトリを作成する．

GitHub Desktop で，Publish repository を押すと，Publish repositoryダイアログが出るので，Publish repositoryを押せばよい．

ここで，”Keep this code private”にチェックをつけると，プライベートリポジトリ（他のユーザーに公開されない）に，外すとパブリックリポジトリ（他のユーザーに公開される）になる．

ここで，GitHubの自分のページにアクセスすると，リポジトリが追加されていることが確認できる．

また，GitHub上でリモートリポジトリを直接作ることもできる．

ページの右上にある＋>New repositoryより，各種入力をして，”Create repository”を押せば作成される．

フェッチ

フェッチ（fetch）とは，リモートリポジトリの状態を確認することであり，定期的に自動で行われる．
また，GitHub Desktopで，Fetch originを押すことで，手動でも可能．

プル

プル（pull）とは，リモートレポジトリの変更をローカルレポジトリに同期させる操作のこと．

フェッチで，まだプルされていないコミットが見つかると，GitHub Desktopでは，Fetch originのボタンがPull originに切り替わり，ここを押すと（またはCtrl+Shift+Pで）プルができる．

プッシュ

プッシュ（push）とは，ローカルレポジトリの変更をリモートレポジトリに同期させる操作のこと．

プッシュの前には，フェッチ，プルをすることが必要．

ここで，リモートレポジトリにまだプルされていないコミットがある場合は，マージ（merge）が行われ，マージコミットが作成される．

無視ファイル

レポジトリに含めたくないファイル（一時ファイルなど）を無視ファイル .gitignore で登録できる．

GitHub Desktopでは，対象ファイルがChangesに現れた時に，右クリック>Ignore fileで .gitignoreに追記，設定される．

詳細は別ページにまとめる予定

共同編集

コラボレーターの設定

パブリックレポジトリでは，誰でも閲覧，クローンはできるが，編集はできない．

（編集権限のないパブリックリポジトリをクローンした後，自分のリモートリポジトリを作ればそこで編集できる．これをフォーク（fork）という．）

パブリックでもプライベートでも，レポジトリを共同編集するには，コラボレータ―の設定をする必要がある．

コラボレータ―を設定するには，GitHubのレポジトリのページから，Setting>Manage accessでパスワードを入力し，Invite a collaboratorを押して表示されるダイアログで相手のユーザー名を検索して招待すればよい．

相手が招待メールを承認すれば登録が完了する．

登録したコラボレーターはManage Accessの下に表示され確認可能である．

コンフリクト

共同編集したときに起こる変更の競合がコンフリクトである．

機械的に競合を解消できるものはGitが自動で処理をするが，それが難しい場合は，手動で処理をする必要がある．

コンフリクトが発生する状態でプルをすると，”Resolve conflicts before merging origin/main into main”ダイアログが表示され，コンフリクトを解消するように促される．

ここで，エディタを開くと，コンフリクトの発生部分が次のように示されている．

<<<<<<< HEAD
コンフリクト発生部分のローカルレポジトリの内容
=======
コンフリクト発生部分のリモートレポジトリの内容
>>>>>>> (コミット番号)

内容を正しいものに書き換え，上書き保存した後，GitHub Desktopに戻って，”Commit merge”を押せばマージコミットが作成される．

これをリモートレポジトリにプッシュすれば，コンフリクトは解消である．

ちなみに，Abort mergeを選択すると，プルしたことがなかったことになる．
もし，マージの編集が住んでいたとしても，その編集は消え，元のローカルレポジトリの状態に戻る

ブランチ

ブランチとは，コミットの履歴の枝分かれである．

作業はブランチで行い，完成したらmainにマージするのが開発の流れである．

また，複数のブランチを作り作業分担をすることも可能．

GitHub Desktopでは，新しいブランチは Current branch>New branch で作成する．

ブランチ内でも同様にコミット，プルが可能である．

チェックアウト

ブランチを切り替える操作をチェックアウトという．

GitHub Desktopでのやり方は，current brachをクリックし，切り替え先のブランチを選択するのみである．

この操作によって，ディレクトリの内容も現在のブランチの内容に対応したものに入れ替わる．

因みに，GitHub Desktopでは，コミットをしないままブランチの変更をしようとすると，内容の変更をブランチの変更先に持ち込むか，現在のブランチで後でコミットするか選択が可能である．

後に変更前のブランチに戻ってきたときに，Stashed Changesを選択し，Restoreを選択することで，この変更は再度反映される．

逆にこの操作をしなければ変更は反映されないままの状態となる．

ブランチのマージ

main→sub

mainブランチのコミットをsubのブランチに取り入れる．

GitHub Desktop で，マージするsubのブランチを開き，メニューバーのBranch>Update from main でmainのコミットがマージされる．

sub→main

subのブランチのコミットをmainに反映させる．

GitHub Desktop で，マージするmainのブランチを開き，メニューバーのBranch>Merge into current branch でMurge into mainダイアログが表示される．

ここで，取り込むsubブランチを選択することで，マージされる．

ブランチの削除

GitHub Desktop で，現在のブランチを削除するには，メニューバーから，Branch>Deleteを選択する．

Delete branchダイアログが表示されるので，Deleteを押すとブランチが削除される．

なお，”Yes, delete this branch on the remote” にチェックを入れるとローカルだけではなく，リモートレポジトリからも削除される．

ただし，ブランチは作業終了後も残しておくのが一般である．

プルリクエスト

プルリクエストとはGitHubに用意されている，作成した変更をマージする際の通知システムのこと．

プルリクエストの作成

作業をブランチで行っており，これをメインに統合したいとする．

GitHub Desktopでプルリクエストを作るには，作業を終えたブランチにおいて，メニューバーからBranch>Create pull request または Ctrl＋R をすると，ブラウザで作成ページが開かれる．

ここで，プルリクエストのタイトル，説明を記入し，”Create pull request”を押すことでプルリクエストが作成される．

特に特定の人にレビューをしてほしい場合，Reviewersから設定することができる．

プルリクエストのレビュー

プルリクエストをレビューするには，GitHubのPull requestsタブから該当プルリクエストを選択し，Commitsタブを選択する．

すると，コミット一覧が表示されるので，レビューするコミットを選択する．

変更の差分が表示されるので，コメントしたい行にカーソルを合わせ（ドラックで複数行選択も可），表示される+マークをクリック，コメント入力欄が表示される．

コメットを入力し，”Start a review” または “Add review comment” でコメントが投稿される．

一連のコメントを入力し終わったら，”Review changes”を押し，レビューのまとめの説明を入力，Comment（ただのフィードバック），Approve（変更の承認），Request changes（訂正の要求）を選択し，Submit Reviewを押せばレビューが送信される．

レビューへの対応

レビューの内容は，GitHubのPull requestsタブ，Conversationsから確認できる．
また，ここからレビューに返信も可能．

レビューを受けて，内容を変更するには，ローカルレポジトリの当該ブランチで編集をし，コミットをプッシュすればよい．

プルリクエストのマージ

当該プルリクエストのページで，”Merge pull request”を押せばマージが完了する．

この操作はコラボレーターならだれでも可能．

参考文献