使い方その2(Git, GitHub資料4)

#使い方その2

ここではチーム開発をする上で必要なコマンドや、GitHubの機能を紹介します。

#ブランチ

$ git branch
を打つことによって、現在のブランチを確認することができます。
$ git branch -a
を打つと全てのブランチを確認することができます。

Gitにはブランチルールがあります。これに沿って開発を行うことにより、スムーズにチーム開発を行うことができます。
ブランチを以下のように想定します。
masterブランチ:リリースした時点のソースコードを管理するブランチ(安定しているコードを置く)
developブランチ:開発作業中のブランチ

$ git checkout -b [ブランチ名]
で、ブランチの作成と切り替えができます。

ここでGitバージョン2.23.0で、git checkoutにあまりにもできることが多いため、役割を明確に分けるためにgit switchコマンドとgit restoreコマンドが追加されたので、このページの最後で紹介します。

#頻出コマンド

$ git log
これを行うとコミット履歴の閲覧ができます。

$ git status -s
これは各ファイルの状態を確認するコマンドです。
以下は実行したときに出力されるものの意味です。
M:変更
A:追加
D:削除
R:ファイル名の変更
??:Git管理していないファイル

$ git fetch
Gitの最新状態を取得するコマンドです。
あるメンバーがpushすることによってそのメンバーのみが最新の状態にある時、他のメンバーがこのコマンドを使用することによってリモートリポジトリの変更点を反映することができます。

#Pull Request, Merge

Pull Requestは簡単に言うと、開発者のローカルリポジトリでの変更を他の開発者に通知する機能です。これには以下のような機能があります。

• 機能追加や改修などの作業内容を他開発者に通知
• ソースコードの変更箇所を分かりやすく表示
• ソースコードに関するコミュニケーションの場の提供

これを行うことによって、バグが起こりにくくなります。
これはある作業が終わって、pushした後に行います。

Mergeとは簡単に言うと、ブランチを合流させることです。
以前、ブランチをパラレルワールドを作成して、のちに元の世界に収束させることもできると表現しましたが、Mergeは収束させるというところに当たります。

例えば、developを変更してその内容をmasterに反映させたい！と言う時にMergeを使います。

ちなみに、pull = fetch + mergeといった感じになります。
つまりpullする必要はないということになります。
fetchとmergeを行うことによって、よりミスなどがなくなるようにpullと同じ作業が行えます。

ここで、チーム開発をしていて同じファイルを違うブランチで編集している時にMergeさせようとすると不具合が起きてしまいます。
これを**「コンフリクト」**といいます。日本語で「衝突」「不一致」という意味になります。
このコンフリクトを解決するのにGitHubを用いるととても効率よく行うことができます。

###やり方
これはGitHubの機能なのでまずはリモートの方で行います。

• リモートリポジトリのページへ行き、「Compare & pull request」を押します。
• Open a pull requestの下の部分を「変更内容を反映させたいブランチ」←「内容を変更したブランチ」となるようにする。
• pull requestのタイトルと説明を入力します。
• 「Create pull request」を押します。これでpull requestの作成が完了しました。
• Pull requestsのページへ行きます。
• コンフリクトが起こった場合は「Resolve conflicts」を押します。すると、

<<<<<<< [内容を変更したブランチ]
[[内容を変更したブランチ]の変更内容]
=======
[[変更内容を反映させたいブランチ]の変更内容]
>>>>>>> [変更内容を反映させたいブランチ]

といったようにお互いの変更内容が表示されます。

• 上記の部分を直接書き直します。書き直したら、右上の「Mark as resolved」を押します。この作業をコンフリクトが起こったファイルの分だけ行います。
• 全て書き直したら「commit merge」を押します。
• 「Merge pull request」を押します。
• 「Confirm merge」を押します。(コンフリクトが起こらなかった場合はこの工程までそのまま行きます。)
• 完了したらいらなくなったブランチを「Delete branch」で消します。
  これで、リモートでの作業が完了しました。

次に、ローカルに反映させます。
$ git fetch
$ git merge origin/[変更内容を反映させたいブランチ]
その後、いらなくなったブランチを消します。
$ git checkout -d [ブランチ名]

これで全て完了です。

#switch, restore

さっきも言った通り、Gitバージョン2.23.0でgit checkoutにあまりにもできることが多いため、役割を明確に分けるためにgit switchコマンドとgit restoreコマンドが追加されました。

以下のように使います。
ブランチの変更はgit switch
ファイルの変更はgit restore
で行えます。今までどうりgit checkoutも使うことができますが、バージョンが2.23.0以降の人はswitch, restoreを積極的に使っていきましょう。
以下は使用例です。

###switch
ブランチの切り替え
$ git checkout [ブランチ名]
$ git switch [ブランチ名]

ブランチを新規作成して切り替え
$ git checkout -b [ブランチ名]
$ git switch -c [ブランチ名]

###restore
ファイルの変更を取り消す
$ git checkout -- [ファイル名]
$ git restore [ファイル名]

特定ファイルを特定のコミットの状態にする
$ git checkout [コミットid等] -- [ファイル名]
$ git restore --source [コミットid等] [ファイル名]

などなどです。他にもいろんなコマンドがあるので調べてみてください。

#番外編

ここではリポジトリの作り方のときにスルーした、「README.md」と「.gitignore」について説明していきます。

###README.md
READMEとはプロジェクトについての説明書みたいなものです。
その名の通り、俺を読めということです。これが重要な役割を担っていて、プロジェクトを公開した際にリポジトリを見て使ってくれるかどうかの第一歩はREADMEにかかっているといっても過言ではありません。

READMEには大きく分けて2つの役割があります。

• プロジェクトの使い方、インストール方法
• プロジェクトの宣伝

です。

READMEはローカルでもリモートでも編集できます。

README作成を始めに飛ばした人はGitHubのリポジトリのページへ行き「Add a README」から中身を書いて「Commit new file」で作成、もしくはローカルでRAEDME.mdというファイルを作り、add, commit, pushすれば完了です。

###.gitignore
.gitignoreとはGitリポジトリにおいて、意図的に追跡対象から外したい(無視したい)ファイルを設定するためのファイルです。
例えばどのようなファイルが追跡対象かというと、ビルドファイルやドキュメント、アプリケーションのリソース(画像など)、テストコードなどです。

書き方(ファイルの中身)
特定の拡張子を無視する場合は
*.[任意の拡張子]
特定のファイルを無視する場合は
/[任意のファイル名]
特定のディレクトリを無視する場合は
/[任意のディレクトリ]/
などなどです。

**#**でコメントアウトできるので説明などを書くと良いでしょう。

###続き
使い方その3(Git,GitHub資料5)