学習[42]日目 - プログラミング未経験おじさんの備忘録

本日の学習

GitとGit hubに関して

そもそも同じものであるという認識でした。。

Gitはアプリケーションなどのプロジェクトをバージョン管理してくれるシステムのことでGitHubはそのGitの仕組みを用いて簡単に複数人での開発ができるようにしてくれるツールでgitにおけるリモートリポジトリの役割を果たしている(リモートリポジトリに関しては下記に記述します。)

Gitを説明するだけでも横文字だらけで分かりづらいと思いました。。

そもそも使い始めるのにどこからという感じですが、railsでアプリケーションを生成したものを管理するとして話を進めていきます。

まずは管理したいディレクトリ下でターミナル上においてgit initを実行することで隠しディレクトリである.gitが作成されて、ディレクトリに対してリポジトリ（入れ物）が付与されgitで管理ができるようになります。

ここでも見慣れない言葉が出てきますが、リポジトリはディレクトリやファイルの変更履歴を記録することが出来る入れ物のことです。

上記のリポジトリにも２種類あり、リモートとローカルリポジトリがあります。

ローカル...は、名前のまんまローカル環境に置くリポジトリのことで、
自分のPC上にあるファイルやディレクトリのバージョン管理を行いたいときに使います。

一方で、リモート...は外部のサーバーなどのネットワーク上に置くリポジトリのことで、

ネットワーク上に置くことで、複数人で管理下のファイルやディレクトリを共有することが出来るものです。
なので自分のPCでデータが消えたりするトラブルが生じても、リモートリポジトリからダウンロードして元に戻す(いわゆるクローンと呼ばれる操作)ことが出来る特徴があります。

この役割を担うのが、今回出てきたgit hubになります。

クローンはリモートリポジトリを複製してローカルリポジトリを作成することで、リモートリポジトリの内容をそのままダウンロード出来ます。

さて、リポジトリの話で手順から一気に脱線してしまいましたが、元に戻ります。

ここからも脱線が多々起きる可能性があります。

ここからバージョン管理できるようになったわけなのでどういう構造で管理していくかをささっと書いてみます。

　　　ワーキングリー(現在、作業中の場所)

status 　 ↓　addする前にインデックスに追加される変更修正内容を確認可能

add ↓　インデックスに追加して変更修正記録の対象にできる

　　　インデックス(バージョンを記録するためにファイルを一時的に登録する場所)

commit ↓　インデックスに変更修正待ちとなったディレクトリやファイルの状態を記録する

　　ローカルリポジトリ

push ↓

　　リモートリポジトリ

早速脱線ですが、

※インデックスのメリットは一度に多くのファイルを変更した際に、どのファイル単位でコミットするかを選択することが出来る。
インデックスに登録したファイル単位が一つのコミットとなるために、どのファイルをインデックスに登録するかを決める必要がある

※コミットすることで現在の状態が、日時や変更を加えた人の情報を含めて一緒に保存することが出来るが、コミットする際にはgit commitに -m 'メッセージ'追加することでさらにメッセージとして情報を追加することが出来る

気をつけるべき点はコミットはなるべく1つの機能ごとにコミットをすることで、基本的にファイルを元に戻したいと思ったときには、コミットごとでしかファイルを元に戻すことが出来ないことに注意しなければいけない

尚、commitした履歴に関してはgit logで表示して確認可能

リモートリポジトリの作成についてはgit hub上で作成を行い、ローカルとの紐付けをgit remote add origin "リモートリポジトリのURL"で行います。

originに関してはgit hub上でリモートリポジトリにつける名称の一般的な命名らしいです。

話を戻して、上の構造でいうローカルリポジトリをgit initで作成したので、アプリケーション上の適当なファイルのコードを適当に変更します。

この変更をインデックスに移すためにgit addします。

git addによってインデックスに変更の記録が出来たことはadd前後でのgit statusの内容によって確認出来ます。

次いで、git commitによりローカルリポジトリに変更を反映が出来ます。

こちらはgit logによって変更反映の有無が確認出来ます。

先程commitしてきた内容に関してはgit hub上でローカルとリモートリポジトリの紐付けを行なった後にpushによってローカルリポジトリで加えた変更をリモートリポジトリに同期させることが出来ます。

このような流れで構造上進んで行くようです。

ここからは、git hubの用語について理解しないといけないものを記載していきます。

ブランチ

リポジトリで管理をしているプロジェクトの履歴の1つで、ブランチ同士は独立しているために、それぞれのブランチ干渉しあってはいない。
メリットとして開発者ごとに担当する機能を明確に分けることが出来ることや完成途中や問題のあるソースコードをリリースしないで済むことがあります。

プル

リモートリポジトリの変更履歴をローカルリポジトリに反映させる操作のことです。
他の開発者による変更がリモートリポジトリに反映された後や、自分でマージを行った際には必ずこのプルの作業を行って最新の状態にしてから次の編集を行わないとマージする際にコンフリクトの可能性が高くなってしまいます。

プルリク

作成したブランチをmasterブランチにマージをするときの確認作業のこと。
ブランチ間の差を他の人からレビューを貰うことで間違えたままリリースする事を防ぎます。

マージ

ブランチとブランチを結合すること。
結合する側のブランチを結合される側のブランチにマージを行うと、結合する側のブランチの内容が結合される側のブランチに反映される。

コンフリクト

複数の人が同じ箇所を編集してしまい、変更箇所を自動では判断できすにマージできなくなる事を言います。

起きる条件をしては、

●2つのブランチで同じ箇所のソースコードを編集
●片方のブランチをマージし、もう片方のブランチを同じブランチにマージ
という2つの条件が起こったときに発生します。

gitignore

gitの管理対象から管理を外すためのファイルやディレクトリを指定するためのファイルで、gitignoreにファイルやディレクトリを指定すると、管理対象から外すことができます。
管理対象から外すとgithubにコードやファイルを同期させ無くて済みます。

長文で画像もなく非常に見辛いですが、編集に時間をかけると学習の進行が遅れるのでまとめはほどほどにしたいと思います。見て下さった方には申し訳ないですが。。

最後まで、見て下さった方には深く御礼を申し上げます。