yuri memo

コーディングとかのメモ帳

GitとGitHub初心者が最初にメモしたこと

f:id:yurixxx8:20170918234801j:plain

初心者の気持ちを忘れる前に一旦メモっ。

Gitとは

一言で雑に言うとバージョン管理システムです。
変更を記録してくれて、その変更履歴を管理できます。
変更の記録・管理ができると「この前の状態に戻したい」という事が簡単にできたり、「どれが最新のファイル・・?」といった事が減ります。
誰が・いつ・どのファイルの・どこを・どのように変更したかが分かります。

GitHubとは

GitHubとは、Gitをさらに便利に使うためのwebサービスの1つです。
私は最初GitとGitHubの違いってなんなの?となったのですが、最終的に「リモートリポジトリの置き場+プルリクエスト(PR)やIssuesが使える便利なやつ」という解釈をしました。

これに関しては検索すると記事がいろいろ出てきますが、まだ触った事ない人は実際にやってみると更に理解できるかと思います。

参考:
エンジニア必須の知識! GitとGitHubの違いとは? | Webデザイン・Webデザイナースクール

GUIでもCUIでも使える

Gitを使うときは主にコマンドラインツール、いわゆる黒い画面を使います。
が、SourceTreeなどを使ってマウスでポチポチすることもできます。
コマンドラインツールを使うと勉強にもなりますが、普段から触っていないと敷居が高く感じられるかもしれません。
私も最初はSourceTreeを使っていました。
(最近になってコマンドラインから操作し始めました)

よく使うワード一覧

GitやGitHubを使い始めると以下のワードがよく出てきます。
一度に全部理解するのは無理なので、最初のうちは「そういうのがある」くらいに思ってました。

[ branch ]
履歴を枝分かれさせて記録する機能

[ clone ]
リモートリポジトリの複製を自分のPCにダウンロードし、ローカルリポジトリとする

[ Hunk ]
編集個所の一つのこと

[ fetch ]
リモートリポジトリに関する情報を更新

[ merge ]
ローカルの状態を、取得した最新のリモートリポジトリの状態に合わせる(統合)

[ pull ]
fetchとmergeを合わせた操作

[ origin ]
リモートリポジトリの場所(URL)の別名

[ master ]
リモートリポジトリのブランチの名前

[ checkout ]
作業対象となるブランチ(コミット)を切り替える

参考:
Gitが、おもしろいほどわかる基本の使い方33

複数人での開発

複数人での開発時に気をつけるポイントを上げてみました。

  • 作業開始時点で必ずプルするように習慣づける
  • プッシュする前にもプルする

この2つは主にコンフリクトの発生率を下げるために気をつけています。
コンフリクトについては後述します。

  • マージ済みや、不要になったブランチは削除する

作業が完了してマージしているにもかかわらず、そのブランチを削除せずにそのまま置いておくのはあまりよくありません。
削除せずにブランチが増え続けると、全体の見通しが悪くなり、混乱の元となります。

コンフリクトについてざっくり話すと

  • Aさんがmain.jsの28行目を変更し、コミット→プル→プッシュまで完了
  • Bさんもほぼ同時に作業しており、Aさんと同じくmain.jsの28行目を変更
  • Bさんがコミットしプルしようとしますが、エラーが起きてしまう

同じファイル(main.js)の同じ行(28行目)を修正しているため、どちらの変更が正しい変更なのかGitでは判断できず、コンフリクト(変更の衝突)が起こります。
コンフリクトが発生した場合は手動で修正する必要があります。

極力コンフリクトを回避するために、作業開始時にプル→作業→コミット→プル→プッシュを心がけています。

参考:
git mergeでの競合(コンフリクト)の解決方法のまとめ。 | WWWクリエイターズ

プルリクエス

プルリクエスト(PR、プルリクとも言います)とは、自分の行った変更について他の作業者(レビュワー)に、
「コードをこのように変更しました。コードレビューをお願いします。」というリクエストを出すことです。
他の作業者にコードレビューをしてもらうことで、見落としていたミスを修正できたり、「こういう書き方もできるけど、どうかな?」とアドバイスをもらえたりします。
このようなコミュニケーションが、ソースコードのクオリティアップに繋がります。

参考:
GitHubでのプルリクエスト活用方法まとめ - ICS MEDIA

コミットするときのポイント

これは私が実際にいただいたアドバイスですが、

コミットログの並びを見るだけで、ある程度環境構築の手順を再現できる(もしくはかつて何をやっていたかが分かる)

ということを意識してコミットすると、cherry-pickでコミットの流用がしやすくなったり、他の作業者はもちろん、自分で後から見返した時にも分かりやすくなります。

cherry-pickとは、他ブランチの特定コミットのみを反映することができるコマンドです。

例えば、ちょっと雑な例ですがこんな感じでしょうか。

  • 環境構築に必要なファイルの追加

↓ 前述のことを意識してコミットすると

  • node-version の指定
  • .gitignore の作成
  • package.json の作成
  • css-loader, node-sass の追加

”環境構築に必要なファイル” だけでは、どこまでの環境構築?なにが入れてあるの?となってしまいますが、分けてコミットすることで、ある程度何が行われたかが分かります。

ソースコードはもちろん、コミットログも自分や他の作業者が理解しやすいよう心がける事が大切だと学びました。

Gitを使い始めた頃はいまいちピンとこなくて、記事をたくさん読んだり本を買ったりしましたが、使えば使うほど便利だなぁと感じています。
これから入門するのであれば、[わかばちゃんと学ぶ Git使い方入門]や[Gitが、おもしろいほどわかる基本の使い方33]などがいいかもしれません。
どちらも書籍です。

またメモが溜まったらブログにまとめます。