はじめに
インターン先でプログラミングを勉強中の文系学生。
お世話になっている会社ではGitを使っているみたい。
作業している様子を軽く見せてもらったけど、何をしているかまったく分からん…。
今一度、勉強しなおすか。
Gitとは
Gitはバージョン管理システムの一種。
組織でアプリケーションやシステムを共同で開発するのには欠かせないツール。
プログラマーの作業を分担したり、分担した作業を統括したりすることができる。
これだけでもバージョン管理システムの重要性が伝わってくる。
勿論、Gitの他にもバージョン管理システムは多数存在している。
その中でもGitが多くの会社から選ばれる理由は2つ。
1つ目は、他のバージョン管理システムより使いやすいこと。
GitはLinuxの開発者が作成したから、プログラミングの基礎が分かっている人であれば十分に使いこなせるはず。
2つ目は、フリーライセンスであること。
使いやすいだけでなく、無料で利用することができる。
選ばない理由を探すほうが難しいくらいかも。
Gitの基本用語
Git編：一歩踏み出すフロントエンド入門のGitに関する連載記事を基に、情報をまとめておこう。
リポジトリ
Gitのようなバージョン管理システムは、時系列に沿ってファイルが記録される仕組み。
その記録を保管されるデータベースがリポジトリ。
アルバムをイメージしてもらうのが分かりやすいかな？
後になればなるほど、最新のアプリやシステム、コードが保存される。
また、Gitは不可視フォルダでリポジトリを保管する。
Gitでの操作をしなければ、リポジトリのデータを変更、削除することができない。
セキュリティとかに効果があるのかな?
リポジトリと併用されるワードは次の2つ。
クローン
イニット
クローンは言葉のとおり、複製を指す。
リポジトリのクローンで以前のリポジトリをコピーすることの意味。
git clone (リポジトリのパス)でクローンができる。
イニットは初期化かな?
既にあるリポジトリを初期化するのではなく、自分で空っぽのリポジトリを作成することを指す。
リポジトリのイニットって言われたときには、「自分でリポジトリを作るんだ」ってことだね。
コマンドはgit init。
コミット
リポジトリに今取り組んでいる仕事のコードやファイルを記録することをコミットと言う。
上書き保存みたいなイメージでいいのかな?
Gitでは複数のファイルを一気にコミットしたり、1つのファイルを丁寧にコミットすることもできる。
コミットしなければ、ファイルは変更されないから、かなり重要な用語だね。
Gitでコミットすると、自動的にコミットしたユーザー名が記録されて、コミットメッセージを残すことが求められる。
コミットメッセージを簡単に言えば、注釈。
どういう変更を行ったのかを他の人に逐一説明せずに済むのは効率的で良いね。
誰が見ても分かりやすいコミットメッセージを書けるようにしておこうっと。
ワークツリー
ワークツリーは普通のフォルダ構成と同じ。
違うのは、Gitがフォルダの変更を記録していることぐらいかな。
自分が作業しているファイルが、Gitのリポジトリと異なった場合、ファイルごとに行単位で違う箇所を教えてくれる。
コミットをしない限り、リポジトリの内容は変更されないから、忘れないようにしないと。
ワーキングディレクトリやワーキングコピー`とかいう別名もあるみたいだから、分からない単語を聞いたらちゃんと聞くようにしないとね。
ステージングエリア
ワークツリーとリポジトリの間にあるのが、このステージングエリア。
作業しているファイルの変更はステージングエリアに登録されてから、コミットでリポジトリのファイルに変更が加えられる。
用語として用いることは少ないだろうけど、仕組みとして覚えておいたほうがよさそうだね。
ちなみに、コマンドはgit add
ブランチ、マージ
これが冒頭に出した作業を分担する為に不可欠な存在。
Aさん、Bさんがホームページを作るとしよう。
AさんがHTML、BさんはCSSを作ってもらうとするときには、それぞれのブランチを作成して作業を分担する。
Aさん、Bさんの両方が仕事を終えて、1つのファイルにまとめるのがマージ。
つまり、ブランチで仕事を分けて、マージでまとめる。
人数が多くなればなるほど、この機能は重要になるだろうから、絶対に覚えておかないと。
ブランチの作成は、git branch (ブランチ名)。
ブランチの一覧は、git branch。
ブランチgit checkout (ブランチ名)で、指定したブランチに移動。
これらのコマンドも覚えておこうっと。
リモートリポジトリ
複数人で作業する以上、1つのファイルやリポジトリを共有することもある。
そのファイル、リポジトリのことをリモートリポジトリという。
時間が空くと、誰かがリモートリポジトリを更新しているかもしれないから、適宜更新する癖をつけておかないとね。
更新はgit push origin (ブランチ名)。
ローカルリポジトリ
プログラマー1人1人が手元のマシン上に配置するリポジトリのこと。
ローカルリポジトリで仕事をして、リモートリポジトリにアップロードする感じかな。
ローカルリポジトリはリモートリポジトリをクローンするか、イニットするかのどちらかで作成するみたいだから、覚えておこう。
リベース
リベースはマージとは異なる統合の仕方かな?
マージは分割したものをまとめる。
リベースは分割したものを、後に持ってくる。
とりあえず、リベースをすると直線になるイメージで良いんじゃないかな?
なんでリベースをするかと言えば、履歴を見るときにわかりやすくなるから。
1人や2人くらいにブランチするならともかく、何十、何百人も居る会社で作業を分けて、マージするとなれば分かりづらくなるよね。
誰がどの作業をやってもらっているのかもわかりにくいし。
そのような分岐をなくして、一直線で分かりやすくするのがリベースかな?
詳しい説明は初心者でも分かる！リベースの使い方を解説しますを見て欲しい。
reflag
当然、作業していれば間違いを起こすこともある。
「作業前の状態に戻したい!!」と言うときには、reflagというコマンドを使う。
さっきも説明したようにGitは履歴を詳細に残してくれている。
git reflagで履歴の確認。
git reflag --hardで復元。
これも重宝する操作だろうし、覚えておかないと。
HEAD
現在使用しているブランチが先頭であることを表す。
それより前のブランチはHEAD~○と言う風に表される。
1つ前のブランチならHEAD~1、3つ前のブランチならHEAD~3と言った感じ。
ちなみに、~はチルダと呼ばれる。
また、ブランチをマージされていて、複数の親が存在する場合は、何番目の親かがHEAD^○で表される。
stach
作業中のファイルをコミットせずに、ブランチのチェックアウトを行うと、移動先のブランチにそのファイルが着いてくる。
ただ、移動先のブランチで、そのファイルに変更が加えられていた場合、チェックアウトはできない。
その場合は、ファイルをコミットするか、stashでファイルを一時的に退避させておく必要がある。
stashすることで、ファイルを別の領域に保存でき、後から取り出せるようになる。
便利なコマンドだから、これも覚えておこう。
プルリクエスト
プルリクエストとは、実装前に使用の確認をする工程。
自分が書いたコードを他の人に見てもらうことで、よりわかりやすいコードにしたり、ミスを減らしたりすることができる。
そのほかにも、それぞれの仕事を可視化することで、不明なところを相談したり、より良い仕事にしたりすることができるようになっている。
この工程は忘れないようにしないと…
コンフリクト
みんなが嫌うエラーのこと。
原因としては、同じファイルを複数の人が変更してしまい、マージした際に、どちらの情報を優先するべきか分からなくなってしまう状態。
コンフリクトになると、マージができなくなる。
せっかくの作業がまとめられなくなるから、不備なくマージできるようにしておかないと。
コミットメッセージの書き換え
この作業はgit commit --amendで行える。
このコマンドを打つと、エディターが起動して、コミットメッセージを書き換えられる。
必要になる場面は多そうだし、覚えておこうっと。
revertとreset
どちらもコミットを書き換える為のコマンド。
revertは打消し。
resetは削除。
勉強でたとえると、revertは二重線、resetは消しゴムかな。
つまり、revertだと無効にされたという表示が出て、resetはそれすらも消える感じだね。
ブランチを操作してみる
ここで参考にするのはサルでも分かるGit入門
まずは作業ファイルを作って、空のローカルリポジトリを作成。
$ mkdir sample
$ cd sample
$ git init
そしたら、作業ファイルであるsampleの中にテキストファイルを作って、コミット。
Hello,World!!
$ git add hello_git.txt
$ git commit -m "first commit"
これが終わったら、ブランチの作成。
$ git branch branch1
git branchでブランチがあるかどうかの確認。
$ git branch
branch1
* master
続いて、ブランチの切り替え。
$ git checkout branch1
ちなみに、以下のコマンドで、ブランチの作成と切替が一度にできる。
$ git checkout-b branch1
ここまできたら、hello_git.txtに文章を追加。
Hello,World!!
add change World
そして、branch1にhello_git.txtの追加。
$ git add hello_git.txt
$ git commit -m "input add"
次は、ブランチのマージ。
ブランチをmasterに切り替えて、
$ git checkout master
hello_git.txtの確認。
Hello,World!!
branch1のhello_git.txtと違うことが確認できたら、マージを行う。
$ git merge branch1
ちゃんとbranch1のhello_git.txtに内容が変わっているかを確認する。
Hello,World!!
add change World
最後にブランチの削除。
無事に変更が適用されていれば、branch1はもういらないよね。
$ git branch -d branch1
ちゃんと削除できているか確認。
$ git branch
* master
まとめ
仕事で扱うGitの知識としては、これくらい押さえておけば大丈夫かな?
それでも実際に触ってみないと、不安はぬぐえないだろうしね。
もっとサイトや本を読んで、Gitの知識を身に付けようっと
参考資料
Git編：一歩踏み出すフロントエンド入門
初心者でも分かる！リベースの使い方を解説します
サルでも分かる!Git入門~バージョン管理を使いこなそう~