0コメント

Gitについて学んだことをメモってみる。

なんか、何かしら説明会的なのを通してGitの知識を得た人もいれば、GitHubをはじめにマイクラ鯖のプラグイン等の開発したデータをJenkinsなるCI(継続インテグレーション)ツールなるものを見つけたりと、なんかプログラム的なものに触るとこういったものにやっぱり何かしら触れることが多いようなので、改めていろいろと調べてまとめてみる事にした。


初めてGitに触れるとき、なんかコードをアップロードして共有したりできる仕組みの事なのかな?って感じに認識してはいた。マイクラ関連で若干使ったことがあったからね

じゃあGitって何ってなると、イマイチよく分からないって状態で使ってたな・・・

そもそもGitとは、「分散型バージョン管理システム」なるものらしい。プログラムのコードをバージョン別に管理することで、バグが起きたとき前のバージョンまで戻ることもできるし、要は簡単にバージョン管理ができるという物らしい。

とはいっても大規模な開発なんてもちろんやったことが無いから実感は沸かないけど。バグったらバグった箇所を特定するのは今の規模じゃ難しくないからだろうね。手のつけようがなくなった!みたいなことになったときにロールバック出来るって感じ?なのかな

分散型バージョン管理システムのGitを使うことで、古いバージョンのコードを見る事はもちろん、ファイルの一元管理、こういったバージョン別の編集履歴を誰かと共有する事ができ、複数人で修正した部分を一つに統合することもできるっていう、まあ開発には必要不可欠なシステムみたい。

私もこういうリモートリポジトリを公開してるので、一応若干使ってみたものの
スクリーンショット 2021-08-18 212928.png
まあこんな感じ。Pythonで書いたプログラムをちょくちょく修正しながら自分が使うように書いて使ってる。

ちなみに「リモートリポジトリ」っていうのがサーバー上に設置されて、共有できるようにしてある貯蔵庫らしい。(リポジトリ=貯蔵庫)

スクリーンショット 2021-08-18 213131.png
んで、このパソコン側で直接作業してるディレクトリ。これをコミットすることで、ローカルリポジトリに記録出来る。

基本的に、プログラムを書いて、コメントを書いてコミット、そしてプッシュすることでリモートリポジトリにファイルを置く事が出来るってこと。

あと、パソコン側で直接作業してるディレクトリの事をワークツリーというらしい。さらに、ワークツリーとローカルリポジトリの中間にはインデックスというものがあって、ローカルリポジトリにコミットする前にインデックスへ仮置き(add)することで、複数ファイルを余分なファイルを含まずにコミットできる、という仕組みになっているらしい。


少し気になったのが。リモートリポジトリを丸ごとローカルリポジトリに持ってくる作業をクローンとかいうのだが、これプルとは何が違うのだろうか。って少し疑問になった。リモートリポジトリを丸ごと持ってくるクローンに対して、プルはローカルリポジトリとリモートリポジトリを比較して、差分があるものだけ更新するっていうのがプルらしい。


こっからがイマイチピンときてないので調べに調べまくってみる。

まずブランチ。
スクリーンショット 2021-08-18 214923.png
私のリモートリポジトリにもmasterっていうブランチがある。
Minecraftにも地下を採掘することをブランチマイニングとか行ったりするのだが、これは「木の枝状に採掘する(これにより効率よく鉱石を手に入れられる)」ってものらしい。

つまり、木の枝状。枝分かれしているものって事なのかな

masterブランチが一番中心の木の枝(※統合ブランチと呼ばれる)だけど、新たにブランチを作成して(※トピックブランチと呼ばれる)何かしら編集、例えばバグの修正や機能の追加等を行うことで並行して同時に作業を行われても正確に管理する事が出来るという仕組みらしい。

あと、調べてるとどうやら統合ブランチっていうのは常にリリース版(バージョンの仕様決定版で、動作が安定しているもの)らしい。トリップブランチへの分岐元として安定させていないといけないみたい。

複数ブランチで作業する時、作業するブランチを切り替えるときはチェックアウトという操作で切り替えた後のこれから作業するためのブランチをワークツリーに展開されて、次からのコミットはそのブランチに対して実行されるようになる、という仕組みがあるみたい。

んでトピックブランチを統合ブランチに統合するときってのが、なんか矛盾とか引き起こしそうだけど・・・って思う疑問点ではある。

ちなみにブランチ作成時点の統合ブランチから更新されていない場合は、単純に移動するだけのfast-forward(早送り)マージが出来る。しかし疑問になるのは、そのブランチが分岐した後に統合ブランチで更新された場合。

現環境ではほとんど起きないらしいが、同じところを変更してマージしようとするとコンフリクト(変更点の衝突)が発生するらしい。
そういう場合はgit diffで状況を確認して、git mergetoolを使うことで統合ブランチの変更点を破壊しないようにトピックブランチの変更点を適用するっていう方法があるらしい。恐らく私がブランチを使う事はしばらくないだろうけど、対処法は一応あるって事だね。

まあでも、ブランチを使うような場面でコンフリクトが起きるようなプッシュはあんまし実際起きないみたいっていうか、そういう使い方みたいだから起きないようにだけ気を付けないと。


あとしれっとmargeで統合ブランチとトピックブランチを統合する(そして新しい統合ブランチのバージョンが出来る)ってことを前提にしてきたけど、もう一つrebaseってものもある。

これはトピックブランチを統合ブランチに合体させるというもの。mergeではブランチの履歴がそのまま残るため複雑化しやすいが、rebaseなら直接統合し統合ブランチのみになるが、元のコミットから変更されるので不安定になる可能性があるらしい。
トピックブランチに統合ブランチの最新コードを取り込む時はrebase、統合ブランチにトピックブランチを取り組む場合はrebaseしてからmergeするっていう使い方をするといいらしい。これはよく分からんが・・・


amendオプションを使ってコミットすることで、直前のコミットに対して内容の追加、コメント修正をする事が出来るらしい。コミット漏れ、やったことがあるのでこの機能はとてもありがたいね

コミットを削除・・・というより、公開済みのものを勝手に消せないので打ち消すためにrevertという物も存在するらしい。


最後に、GitHubにあったプルリクエストという物について。

プルリクエストは書いたコードを他の人にレビューしてもらって、変更箇所を明確に指摘してもらいながらコードに関するコミュニケーションの場である。…という事らしい。

会社やチームなどにおいては、レビュー・マージ担当者に通知することも。コミュニケーションなど、そういった場も履歴に残して再議論したり、考案しなおしたりでよりよいコードが作れるように工夫されてるんだなあと感心した。



約二時間ちょいかけてひととおり自分なりに解釈してみた。
コマンドにはまだ触ったことが無いので、近々触ってみようかなって感じ。

この記事へのコメント