Gitのテクニカルタームのまとめ
はじめに
Gitという言葉をよく聞くようになり、ファイルを管理するのに便利そうだということはわかっていたのですが、Git特有の言葉が多く全体像をつかめずにいてなかなか導入できずにいました。Gitに関してはサルでもわかるGit入門というサイトが超わかりやすいのでおすすめです。完全にこちらのサイトの記載を自分のメモ用に箇条書きに直しただけなので、基本は上記サイトを参照下さい。
なぜGitを使いたいと思ったかですが、1つには研究で使用したRの.rmdファイルのバージョン違いが複数出てしまって、どのバージョンがどの記載をしてどんな変更を加えたか？ということが全然把握できない上に、同じようなファイルがたくさんできてしまってフォルダが美しくなくなってしまったから。もう1つには、主に臨床用のメモをテキストファイルとして保存してぱっと参照できるようにしているのですが、最近、markdownを使うようになったので、綺麗に表示できるサービスがあまりないのです。GitHubなどではmarkdownテキストを綺麗に表示できるため、使ってみたいと思いました。これを機にしっかりと勉強して使いこなしたいです。
Git
- 分散型バージョン管理システムの一つ
- もともとLinuxのソースコードを効果的に管理するために開発された
- ファイルの状態を好きなときに更新履歴として保存しておくことができる
- 一度編集したファイルを過去の状態に戻したり、編集箇所の差分を表示することができる
リポジトリ
リモートリポジトリ
- 専用のサーバに配置して複数人で共有するためのリポジトリ
ローカルリポジトリ
- ユーザ一人ひとりが利用するために、自分の手元のマシン上に配置するリポジトリ
コミット
- ファイルやディレクトリの追加・変更をリポジトリに記録するための操作
- リポジトリの内に、前回コミットした時の状態から現在の状態までの差分を記録したコミットが作成される
- リビジョンともいう
- 時系列順につながった状態でリポジトリに格納される
- コミットを最新の物から辿ることで、過去の変更履歴やその内容を知ることができる
- バグ修正や機能追加などの異なる意味を持つ変更は、できるだけ分けてコミットする
- 後から履歴を見て特定の変更内容を探す時に探しやすい
- コミットの実行時にはコミットメッセージの入力を求められる ( 必須 )
- コミットメッセージは必須となっている
1行目 : コミットでの変更内容の要約 2行目 : 空行 3行目以降 : 変更した理由
- 上記の様にコミットを記載するのがマナー
ワークツリーとインデックス
- 実際に作業をしているディレクトリのことをワークツリーと呼ぶ
- リポジトリとワークツリーの間にはインデックスが存在
- インデックスとは、リポジトリにコミットする準備をするための場所
- コミットを実行した時にワークツリーから直接リポジトリ内に状態を記録するのでない
- その間に設けられているインデックスの設定された状態を記録する
- コミットでファイルの状態を記録するためには、まずインデックスにファイルを登録する
インデックスを間に挟むことのメリット
- ワークツリー内の必要ないファイルを含めずにコミットを行える
- ファイルの一部の変更だけをインデックスに登録してコミットすることができる
プッシュ
クローン
- リモートリポジトリを複製する操作
- リモートリポジトリの内容をまるまるダウンロードして、別のマシンにローカルリポジトリとして作成できる
- 変更履歴も複製されている
- 元々のリポジトリと全く同じように履歴の参照やコミットをすることができる
プル
- リモートリポジトリからローカルリポジトリを更新する操作
- リモートリポジトリから最新の変更履歴をダウンロードしてきて、自分のローカルリポジトリにその内容を取り込む
- 複数人がリモートリポジトリにプッシュした結果を取り込む際に用いる
プルリクエスト
- 開発者のローカルリポジトリでの変更を他の開発者に通知する機能
- 機能追加や改修など、作業内容をレビュー・マージ担当者やその他関係者に通知する
- ソースコードの変更箇所をわかりやすく表示する
- ソースコードに関するコミュニケーションの場を提供する
マージ
- 他の履歴での変更を取り込む操作
- マージを行わないまま履歴を上書きし、他の人がpushした変更が失われてしまうことを防ぐ
- 最後のpullからpushまでに、他の人がpushをして更新した場合は、自分のpushは拒否される
- リモートリポジトリとローカルリポジトリでファイル内の同じ箇所を変更していた場合は自動更新されない
- どちらの変更を取り込むか自動では判断できないのでエラーが発生する
- 競合が発生した箇所を手動で修正する必要がある
フェッチ
- リモートリポジトリの最新の履歴の取得だけを行うことができる
- 実はプルは内部でフェッチとマージを同時に行っているものと考えるとわかりやすい
- 取得したコミットは、名前の無いブランチとして取り込まれる
- FETCH_HEADという名前でチェックアウトすることができる
- FETCH_HEADをマージするか、改めてpullを実行するとローカルにmasterが統合される
- 単にリモートリポジトリの内容を確認したいだけの時、マージをしたくない場合に行う
- pullを実行すると、リモートリポジトリの内容のマージが自動的に行われてしまうため
ブランチ
- 並行して行われる複数の機能追加やバージョン管理を支援する
- 履歴の流れを分岐して記録していくためのもの
- 分岐したブランチは他のブランチの影響を受けない
- 同じリポジトリ中で複数の変更を同時に進めていくことができる
- 分岐したブランチは他のブランチと合流(マージ)することで、一つのブランチにまとめ直すことが出来る
- 自分の作業専用のブランチを作成し、作業が終わったらメインのブランチに自分のブランチの変更を取り込む
- 他のメンバーの作業による影響を受けることなく、自分の作業に取り込める
- 作業単位で履歴を残すことで、問題が発生した場合に原因となる変更箇所の調査や対策が容易
マスターブランチ
- リポジトリに最初のコミットを行った時に作成されるブランチ
- ブランチを切り替えるまでは、コミットはマスターブランチに追加されていく
統合ブランチ
- リリース版が何時でも作成可能なようしておくためのブランチ
- トピックブランチの分岐元としても使用する
- 安定した状態を保っておくことが重要
- 何らかの変更を行う場合は、トピックブランチを作成して作業を行うことが多い
- 通常、masterブランチを統合ブランチとして使用する
トピックブランチ
- 機能追加やバグ修正といったある課題に関する作業を行うために作成するブランチ
- 複数の課題に関する作業を同時に行う時は、その数だけトピックブランチが作成される
- トピックブランチは安定した統合ブランチから分岐する形で作成する
- 作業が完了したら統合ブランチに取り込む
チェックアウト
- 作業するブランチを切り替えること
- まず移動先のブランチ内の最後のコミットの内容がワークツリーに展開される
- チェックアウト後に行ったコミットは、移動後のブランチに対して追加されるようになる
HEAD
- 現在使用しているブランチの先頭を表す名前
- デフォルトではmasterの先頭を表している
- HEADが移動することで、使用するブランチが変更される
- コミットを指定するときに、~(チルダ)とキャレットを使ってあるコミットからの相対位置で指定することもできる
- この時に、HEADがよく使われる
- ~ ( チルダ )
- 後ろに付け加えることで何世代前の親かを指定することができる
- ^ ( キャレット )
- ブランチのマージで親が複数ある場合に、何番目の親かを指定することができる
stash
- ファイルの変更内容を一時的に記録しておく領域
- ワークツリーとインデックス中でまだコミットされていない変更を一時的に退避させることができる
- 退避させた変更は後から取り出して、元のブランチや別のブランチに反映させることができる
- コミットしていない内容がインデックスやワークツリーに残ったままで、他のブランチへのチェックアウトを行うと、その変更内容は元のブランチから、移動先のブランチに対して移動する
- 移動先のブランチで、同じファイルが既に何らかの変更が行われている場合はチェックアウトに失敗する
- このような時にstashを使って一時的に変更内容を退避させることができる
