Git
Gitを使ったバージョン管理
・Gitでは、ファイルの状態を好きなときに更新履歴として保存しておくことができます
→古いファイルを元に編集したファイルで、他人の編集した最新ファイルを上書きしようとすると、サーバにアップロードした時に警告が出る
履歴を管理するリポジトリ
・リポジトリとは、ファイルやディレクトリの状態を記録する場所。
→・リモートリポジトリ
専用のサーバに配置して複数人で共有するためのリポジトリ。
・ローカルリポジトリ
ユーザ一人ひとりが利用するために、自分の手元のマシン上に配置するリポジトリ
・リポジトリの作成には
・新しいリポジトリを作成する方法
・リモートリポジトリをコピーして作成する方法
で二つある。
変更を記録するコミット
・ファイルやディレクトリの追加・変更を、リポジトリに記録するにはコミットという操作を行います
→コミットを実行すると、リポジトリの内では、
前回コミットした時の状態から現在の状態までの差分を
記録したコミット(またはリビジョン)と呼ばれるものが作成されます。
これらのコミットには、コミットの情報から計算された重複のない英数字40桁の名前が付けられています。この名前を指定することで、リポジトリの中からコミットを指定することができます。
・コミットの実行時にはコミットメッセージの入力を求められます。
コミットメッセージは必須となっているため、空のままで実行するとコミットが失敗します。
ワークツリーとインデックス
・Gitの管理下に置かれた、みなさんが実際に作業をしているディレクトリのことをワークツリーと呼びます。
・Gitではリポジトリとワークツリーの間にはインデックスというものが存在しています。
インデックスとは、リポジトリにコミットする準備をするための場所のことです。
このようにインデックスを間に挟むことで、ワークツリー内の必要ないファイルを含めずにコミットを行ったり、ファイルの一部の変更だけをインデックスに登録してコミットすることができます。
リモートリポジトリにプッシュする
・リモートリポジトリで自分の手元のローカルリポジトリの変更履歴を共有するには、ローカルリポジトリ内の変更履歴をアップロードする必要があります。
→Gitではプッシュ(Push)という操作を行います。
Pushを実行すると、リモートリポジトリに自分の変更履歴がアップロードされて、リモートリポジトリ内の変更履歴が ローカルリポジトリの変更履歴と同じ状態になります。
ブランチとは
・ブランチとは、履歴の流れを分岐して記録していくためのものです。
分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。
また、分岐したブランチは他のブランチと合流(マージ)することで、一つのブランチにまとめ直すことが出来ます。
チームのメンバーは、他のメンバーの作業の影響を受けないように、メインのブランチから自分の作業専用のブランチを作成します。 そして作業の終わったメンバーは、メインのブランチに自分のブランチの変更を取り込んでいきます。
→このようにすることで、他のメンバーの作業による影響を受けることなく、自分の作業に取り込むことができます。
・また、作業単位で履歴を残すことで、問題が発生した場合に原因となる変更箇所の調査や対策を行うことが容易になります。
・リポジトリに最初のコミットを行うと、Gitはmasterという名前のブランチを作成します。
そのため、以後のコミットはブランチを切り替えるまでmasterブランチに追加されていきます。
ブランチの運用
・自由にブランチを作成することができるが、ブランチを効果的に利用するには、
あらかじめ運用ルールを設けておくことが重要。
→統合ブランチとトピックブランチという二種類のブランチを使った運用方法がある
・統合ブランチとは、リリース版が何時でも作成可能なようしておくためのブランチです。
また、トピックブランチの分岐元としても使用します。
そのため、安定した状態を保っておくことが重要です。
何らかの変更を行う場合は、トピックブランチを作成して作業を行うことが多いです。
・トピックブランチとは、機能追加やバグ修正といったある課題に関する作業を行うために作成するブランチです。
複数の課題に関する作業を同時に行う時は、その数だけトピックブランチが作成されます。
トピックブランチは安定した統合ブランチから分岐する形で作成し、作業が完了したら統合ブランチに取り込むという使い方をします。
ブランチの切り替え
・作業するブランチを切り替えるには、チェックアウトという操作を行います。
チェックアウトを行うと、まず移動先のブランチ内の最後のコミットの内容がワークツリーに展開されます。
また、チェックアウト後に行ったコミットは、移動後のブランチに対して追加されるようになります。
・HEADとは、現在使用しているブランチの先頭を表す名前です。
デフォルトではmasterの先頭を表しています。HEADが移動することで、使用するブランチが変更されます。
・stashとは、ファイルの変更内容を一時的に記録しておく領域です。
stashを使うことで、ワークツリーとインデックス中でまだコミットされていない変更を一時的に退避させることが
できます。
退避させた変更は後から取り出して、元のブランチや別のブランチに反映させることができます。
ブランチの統合
・作業が完了したトピックブランチは、最終的に統合ブランチに統合されます。
→ブランチの統合には、mergeを使う方法と、rebaseを使う方法の2種類がある
(どちらを使うかで統合後のブランチの履歴が大きく異なります。)
・mergeを使用すると、複数の履歴の流れを合流させることができます。
・rebaseを使用すると、mergeと同じだが、仕方が違う。
トピックブランチと統合ブランチでの運用例
このように、ブランチ上手く使うことで異なる作業を並行して進めることができます。
前準備
ブランチを作成する
ブランチを切り替える
ブランチをマージする
ブランチを削除する
並行で作業する
マージでの衝突を解決する
rebaseでマージする
直前のコミットを修正する
・amendオプションを指定してコミットを行うと、
同じブランチの直前のコミットに対して内容を追加やコメントの修正をすることができます。
☆主な利用シーン
直前のコミット漏れしたファイルを後から追加する
直前のコミットコメントを修正する
プルリクエストとは?
・プルリクエストとは簡単に言うと、
開発者のローカルリポジトリでの変更を他の開発者に通知する機能です。
☆プルリクエストは次のような機能を提供します。
・機能追加や改修など、作業内容をレビュー・マージ担当者やその他関係者に通知します。
・ソースコードの変更箇所をわかりやすく表示します。
・ソースコードに関するコミュニケーションの場を提供します。
プルリクエストのメリット
・レビュー・マージ作業をタスク化して管理し、やりとりを記録できる
作成されたプルリクエストは一覧で見ることができるため、未完了のプルリクエストを簡単に確認できます。
そのためレビュー・マージ担当者は作成されたプルリクエストを漏れなく処理できます。
・レビューを促進できる
プルリクエストは、ソースコードの変更部分を明確に表示できます。
また、プルリクエストの作成者は、ソースコードの意図や補足事項をコメントとして伝えることができます。
これらによって、レビュー担当者の負担を減らせます。