GitとGitHubについて

本記事について

プログラミング初心者がGitとGitHubに関する知識を学んだので、その備忘録として載せております。

どうかお手柔らかにお願いいたしますm (- -)(_ _)ペコリ

Git

・ソースコードなどのファイルやフォルダの変更履歴を記録・追跡するためのバージョン管理。

・ファイルのセーブポイントを時系列で追える。時系列に沿った保管が可能。
・ソースコードのバージョンを管理。

・変更ごとにファイルをいちいち更新するという作業がなくなる。
・いつ、誰が、どこを編集したのかがわかる。

GitHub

・GItの仕組みを利用し複数人での開発ができるようなwebサービス。

・クラウドサービスのようにファイルの共有や同時編集、保存ができる。
・世界中の人が自分のプログラムやデザインデータを保存している。

・Gitを利用して複数人での開発をサポートしてくれるサービス
・mergeメソッドで追記も可能

GitとGitHubについて

・アプリケーションを作っている時に、作り直したいという時がある。そこで、ある段階まで残したいなという時にGitで管理してくれる。バージョンの管理の実現。

・多数で開発していると他の人が書いたコードを間違って消してまうこともある。予期せぬ削除やファイルの共有が行いづらい時にGitとGitHubというサービスを組み合わせると便利。

アプリケーション開発における問題

・コードの開発段階で、あるところまで元に戻したいけど、どのファイルをどのように編集すれば良いかわからない
・複数人による開発の際、他人の作ったコードを消してまう。

GItを用いたバージョンの管理

・まずファイルの内容を保存するための箱のようなものを用意する。
・保存する枠組みを用意する必要がある。
・この箱をリポジトリという。

リポジトリ

・Gitの管理下にあるファイルやディレクトリの変更履歴を保管しておく箱のような場所。
リ・ポジトリにはローカルリポジトリとリモートリポジトリがある

ローカルリポジトリ

・自分のPC上（ローカル環境）におくリポジトリ（保管用の箱）
・自分のタイングで更新ができる。保存できるスペース。大枠

リモートリポジトリ

・外部サーバー上におくリポジトリ（保管用の箱）
・インターネットを介している。自分のPCとは別の場所。
・ローカルリポジトリと同期して変更修正を行い、リモートリポジトリを反映させる。
→他の人に自分の作成したコードを共有できたり、チーム開発をしやすくしたりする。

・複数人の開発で使う。
・１人の時でも使える。Gitを使っているユーザーからここが不安とコメントすれば世界中の人からアドバイスをくれる。（プルリクエスト）選択的にこのフォルダにアドバイスをくれと言える。プルリクエストは誰かにチェックしてもらうのに役立つ。

commit

ローカルリポジトリにファイルやディレクトリを保存、変更修正すること。
→時系列で変更修正の管理ができる、また遡ることできる。

コミットメッセージ

・「どのような修正変更なのか」をわかりやすくするためにメモを添える。
・HTML CSS、Rubyのコメントのようなもの。
・中身を確認しなくてもいい。

.DS_Store

・Gitで管理しないようにする不要な変更履歴。ディレクトリの情報を記録するファイル。
・Gitの管理で手間になる。

push

commitで変更を行うと一時的にローカルリポジトリに保管されている状態になる。
→push　変更をリモートリポジトリに反映させること

commit log

commitの履歴の確認方法（Historyから確認可能）●commitの粒度（どの頻度でコミットするのかの頻度）

ある程度コミットは細かくした方がいい。

細かくcommitをするメリット

・作業の進捗を管理
・エラーが起こった際にどこでエラーが起こったかわかるので、エラーが起こった分岐点が分かり、それを境に前後比較できる

→ただ毎回GitHud Desktopを行き来するのは面倒
→それを解決するのがインデックスとaddの概念

インデックス（comittの対象←インデックスに保存されている内容）

変更修正が一時的に保存される場所

add（アド）

ファイルの追加、変更修正をインデックスに登録
すなわちcommitの対象とさせる。インデックスに箱詰めの段階ではまだcommitされていない。インデックスというジャンルに分けて、大きな保管庫リポジトリに保管している。保管庫の中にカテゴリー別で、データが保管されているので、データを取り出しやすい。インデックスは箱
リポジトリは倉庫、addは箱詰め。

GitHubを使うときの暗黙の了解

GitHubは複数人の開発や、１人で開発を行っていても世界中の人からアドバイスをもらうなど、コミュニケーションの中で利用されるウェブサービスなので開発の流れのルールが存在する。そのルールの一つとしてブランチがある。本流と言われる幹となるmasterブランチに影響を与えずに、独立した編集ができ、必要とあらば切り離しもでき、必要とあらば本流に内容を追加することができる。

ブランチ

コミットの連なり　コミットの連続
リポジトリで管理しているファイルやディレクトリの変更の流れ、毎回の変更

##ブランチは分岐可能
本流　→ masterブランチ
分岐したブランチ　→ トピックブランチ

トピックブランチのメリット

・複数人の開発においてMVCのファイルの同時作成、編集変更が起こった際に同じファイルを同時に編集できる。
・本流　masterブランチに影響を与えない
・ブランチを切ることで目的別に同時並行で開発できる
・不具合が発生した場合も対応が簡単になる

プルリクエスト

コミットごとの履歴とともに、各コミットにおける変更修正にコメントをつけることができる機能。誰にかに見てもらうもの。どのような機能に関するプルリクエストなのかwhat（ブランチに何を行ったのか）とwhy（なぜその実装を行ったのか）を記述していく。

whatの部分はアプリケーションの機能が複雑になると、コードをぱっと見ただけではわかりにくいから明記する必要がある。

whyの部分では実装目的を伝えることで欲しいアドバイスをもらえるので明記する必要がある。

マークダウンで書く

マークダウン　記法の一種

コードレビュー

コードの記述内容に関して問題ないか他者が確認を取ること
レビュアー　コードレビューの担当者

merge（統合）

分岐した履歴を戻して統合する手段

pull

・リモートリポジトリの変更をローカルリポジトリに取り込む操作
・リモートリポジトリの情報をローカルリポジトリに反映

LGTM （Looks good to me）

コードには問題ないと思う！

pullとcloneの違い

pull　

ローカルリポジトリとリモートリポジトリがもう既に紐づいている状態で、リモートリポジトリの情報をローカルリポジトリにpull（反映）すること

clone

リモートリポジトリが箱としてwebサービス上にあり、手元にローカルリポジトリが箱としてない状態で、リモートリポジトリからローカルリポジトリを作成すること

→pullとcloneでは作業を始めるデフォルトが違う。
　
自分のアプリケーションを他者に共有する場合のcloneではまず自分が自分のPCでローカルリポジトリを作成作業した後に、自分の作成したローカルリポジトリをリモートリポジトリにpush（反映）する。その反映したリモートリポジトリの情報を他者のPCのローカルリポジトリにpull（反映）する。

push（リモートリポジトリに反映すること）には権限が必要

他者がリモートリポジトリから共有されたデータをpushするには権限がいる。勝手にpushすることはできない。

片方だけ更新できている状態がよくありデータの差分を補う必要がある。（フェッチオリジン）
新しいブランチは今ある状態のマスターブランチをそのまま引き継ぐ。したがって起こりうることとして、自分が思った保存内容で反映されていないことがある。必ずマージの内容を確認、マスターブランチの内容を変更、更新時は確認する。pullした後に、マスターブランチに新規でブランチを作成した内容が反映されていない状態であれば、作業しているローカルのマスターブランチには更新情報が反映されていない状態となる。というのはマスターブランチが幹となり、そのままのマスターブランチの内容をブランチが引き継ぐからである。都度保存内容は確認。ブランチ（１）と（２）は独立しているため、タイムリーに作業するには一度マスターを更新された状態で作業する必要がある。

GitHubを使用するときの流れ

マスターからブランチを作成
ブランチで編集のちにコミット
ローカルとリモートのデータの更新の差分を解消するために、pushでリモートにデータを反映。
プルリクエストを作成公開
レビュアーが確認＋LGTM
リモートのマスターにマージ
リモートとマスターのデータの更新の差分を解消するためにpullでローカルにデータを反映

##ブランチを作成せずにマスターブランチ上でコードを書いてしまった場合
Bring my changes toを選択

stash

現在の作業を一時的に離脱したい、もしくは離脱して作業を元に戻したい時に使用

コンフリクト　

ブランチごとの内容の整合性が合わない現象（お互いごめんちゃいという現象、いざこざ）
→同じファイルを別の人が既に修正しているのでマージできない

コンフリクトを解消するためResolve Conflictsをクリック

複数人の開発ではコンフリクトは発生しやすい。

・コンフリクトを未然に防ごう
・ブランチ作成前にpullを行うこと（最新のマスターブランチの内容を反映させておくこと）
・複数人の開発の際は打ち合わせをしておく

発生のポイントを深掘り

・なぜ発生したのか
・再発防止に努める
・報告連絡相談＋確認

間違ってpushを押してしまった

pushした情報はローカルリポジトリに戻すことはできない。
しかしリモートリポジトリに間違ったcomittは取り消せる。

revert

commitされた変更とは異なる変更を追加することでcommitを取り消す。
指定するcommitを取り消しするためのcommitを追加で行う。

以上です。