ローカルリポジトリ・リモートリポジトリ

リポジトリ：ファイルやディレクトリを保存する場所のこと

ーリポジトリの管理下にディレクトリを置くことで、ディレクトリ内のファイルの変更を記録していくことができる

マシン内にあるローカル/サーバーにあるリモートリポジトリにわかれる

コミット・プッシュ

コミット：ファイルの追加や変更の履歴をリポジトリに保存すること

プッシュ：ファイルの追加や変更の履歴をリモートリポジトリにアップロードするための操作

ブランチ

ブランチ：履歴の流れを分岐して記録していくもの。

分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ内でそれぞれの開発を行っていくことができる

並行して複数のバージョン管理を行うために使用する

Pull Request

When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch. Pull requests show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.

ホスティング

ホスティングサービス(サーバホスティングとも)とはサーバの利用者自身でサーバの運営・管理をしなくてもいいように、有料または無料でサーバ機のHDDの記憶スペースや情報処理機能などを利用させるサービスを言う。

ステージの役割

複数の作業を一度に進めた時に、コミットする時にその中の作業一つ一つを独立してコミットする必要が出てきた時に、ステージが必要

Hunk

編集箇所各一つのことを指す

「破棄」と「削除」

（ステージ追加前に変更内容の誤りを見つけた場合）
- 「破棄」：ファイルに加えられた変更を破棄
- 「削除」：ファイル自体を削除

→似たような言葉だけど、やってることは全く違うので注意

GitHubの使い方

１：GitHubでリポジトリの作成(git init)、または複製(git clone）をする

2：ファイルの作成・編集を行う

3：ファイルの作成・変更・削除をGitのインデックスに追加する(git add)

4：変更結果をローカルリポジトリにコミットする(git add)

5：ローカルリポジトリをプッシュしてリモートリポジトリへ反映させる（git push)

• 基本的に小さい作業単位でコミットを行い、ある程度作業がひと段落したらプッシュする。

• コミットをするときは、コミットメッセージを残しておく

• インデックス：リポジトリにコミットする準備をするために変更内容を一時的に保存する場所のこと

• 作業開始時点で必ずプルを行う

→プルとは実際には「フェッチ(fetch)と「マージ」(merge)という一連の処理。

→中央リポジトリとローカルリポジトリに作業履歴の差分があるとき、作業履歴を統合するための処理が「マージ」(merge)

→ただし、中央リポジトリでマージをすることはできない

→マージは、ローカルリポジトリで処理する必要があるため、作業履歴に差分がある状態でプッシュすることはできず、まずはマージする必要がある

（つまり：）インデックス登録→コミット→プル→プッシュの順番で行う

マージの種類は大きく分けて３つ

実際のマージ処理は４種類の処理結果が詳細情報画面に出力される

• 「Already up-to-date」（更新なし)ー差分を確認したら、両方の環境の内容が同じだったので、マージする必要がなかったとき
• 「Fast Forward」ー片方の環境が古いだけで、もう一方の環境でだけ変更がある場合は、新しい環境を全て正（正しい）として取り込んでしまう場合
• 「Auto Merge」ー両方の環境の差分について、同じファイル中の同じ箇所の変更がなく、自動でマージが完了できた場合
• 「Conflict」ー両方の環境で同じファイルの同じ箇所を変更してしまっていて、作業した人にどうすればいいのか確認が必要な場合

コンフリクトが発生したときは、コンフリクトが発生したファイルだけがマージされない

• コンフリクトしたファイルを修正したとしても、そのファイルが作業ツリーにいる限りは、コンフリクトしている状態であるとGitは認識している

→作業ツリーからステージに追加したことで、Gitにコンフリクトが解決したことを伝える

→裏を返せば、ステージに追加してしまうと「コンフリクトが解決した」とGitが認識してしまうため、もし修正が未完了のままステージに追加してしまった場合は、追加したファイルを元に戻す必要がある

Gitは、ファイルの変更内容をファイルとして管理するのではなく、ファイル内の変更箇所単位「Hunk単位」で管理している

ベア（bare)リポジトリ

作業コピーファイルが存在せず、どのブランチもチェックアクト（check out)されてないリポジトリのこと
→ベアリポジトリ上ではマージができないため、手元のリポジトリからプッシュする際は常にFast Forwardである必要がある。

不慮の全行コンフリクトに注意

• 複数メンバーで作業していると、windows,macなど作業環境の違いで改行コードが書き換わった状態が発生すると、ファイル内の全ての行がコンフリクトの対象になったりする。

• エディタの設定によっては、改行コードだけでなく、文字コードが変わっていたりする可能性もあるし、行末の空白やファイルの末尾の改行を自動的に削除するといったせいっていのあるエディタもあるので注意が必要

→予めエディタを含めた編集ツールの設定を作業メンバー間で協議し、プロジェクトごとに適切に統一しておく必要がある

cf:macの改行コードは「LF」、windowsは「CR+LF」（本p92）参照

技術的なこと

• 隠しファイルは「command + shift + .（コマンド + シフト ＋ ピリオド）」で表示
• コミットは、１作業ごとに行うべき
• 削除したことも、Gitは記録してくれる。記録を残すことがGitの肝
• コミットのショートカットは「Ctrl+Opt+Cのキー」
• コミットと同時にプッシュすることで、他の作業者とのコンフリクトを避けられる
• 同じリポジトリ内で複数の人が同時に作業するときは、お互いの作業を打ち消し合わないように、ブランチをそれぞれ分けて作業を進めていく形になる

【プログラミング超入門】GitHubの使い方｜初心者向けにアカウント登録から解説！

Official Introduction of GitHub

【Gitが、おもしろいほどわかる基本の使い方33　改訂新版】

その他困ったこと

• ファイルをローカルリポジトリに追加するときは、そのファイルがリポジトリ内にある必要がある

• その際の名前は、リポジトリのパスを起点に、相対パスで指定する必要がある