📜

gitが苦手なのでやってることの覚書

2021/08/10に公開

Git

ポエム

tech

gitが苦手です

clone,commit,push位はなんとなく雰囲気で使えますがcherry-pick,revert,rebaseとかなってくると

あれ？これどうやるんだっけ？

とか思った動きと違う動きになったりして混乱します

なのでたまにこれを１からやり直してなんとなく復習したつもりになっています

それでも仕事でマージが発生したりするととても憂鬱です

mainブランチにdevelopブランチをマージしてpushするだけでも本当にこれでいいのかと不安になります

なのでとりあえずローカルで試します

$ cd $(mktemp -d)
$ git clone --bare <リポジトリパス> lesson.git

これで一時ディレクトリにlesson.gitという名前でリモートのgitをbareクローンします

$ git clone lesson.git testrepo

これでクローンしたlesson.gitをリモートに設定したtestrepoリポジトリを作ります

この状態でtestrepoで実際に実行しようとしている一連のgit操作を行い正常に実行できる事を確認できれば実際のリポジトリでも同じように作業できるので事前のリハーサルに使えます

ちなみに私の担当してるシステムは何か改修が発生する度に人手が足りなければ一時的に外注が来てソースを弄ってもらったり私一人で全てやったりするくらいとても小規模な案件です

なのでdevelopブランチとmainブランチの２つだけで管理してます

developブランチで次期案件の改修を行いリリースモジュールを作り正常にリリースが完了した段階で
developブランチを以下のコマンドでマージします

$ git merge --squash develop

これでdevelopブランチのコミット数に関係なくmainブランチにはこんな感じで

$ git log --graph --pretty=oneline
* c101ab6e3e8cb319145d39be337eea06552daf60 (HEAD -> main, origin/main, origin/HEAD) v1.0.2
* 56ae084d26ba620663bcfc7a9c15555c95bcf128 v1.0.1
* a958acd1a08ec44cf8c014ab4409d39505f2ae76 v1.0.0
* 346ec94f12333e50cf78326ebe299b3976c845fb first commit

１コミット＝１リリース
のログとして残るのでわかりやすいです

そしてdevelopブランチ側では

$ git merge main

してmainに出来たsquashコミットをdevelopブランチ側に取り込んでおけば次期案件が始まるとまたdevelopに改修をコミットしていけば良いだけになります

またmainとのマージコミット間が各リリースで行った修正内容の細々したログになるのでログもこんな感じになります

$ git log --graph --pretty=oneline develop
*   e3805f0a8e4186b822c629d301818c07ff1a1d5e (origin/develop, develop) Merge branch 'main' into develop
|\  
| * c101ab6e3e8cb319145d39be337eea06552daf60 (HEAD -> main, origin/main, origin/HEAD) v1.0.2
* | 02ad7b3f0f7e49d94ab4680c218313d0535fe961 add bbb.txt
* | 5f91d25f28ab2f554724b56af37ca37d1009b00c add aaa.txt
* | 8bc660fbb600fc6dbbf9a71d5720ad0278e316b7 Merge branch 'main' into develop
|\| 
| * 56ae084d26ba620663bcfc7a9c15555c95bcf128 v1.0.1
* | d901ba6d802a19e5d36c11eaf5fabacccd973d66 rm bbb.txt
* | e7c0573350ca5b07dbeb706e02aad155dce4288c rm aaa.txt
* | 5945654d05a25ed71b67a49320cb98cc55dbf5a0 Merge branch 'main' into develop
|\| 
| * a958acd1a08ec44cf8c014ab4409d39505f2ae76 v1.0.0
* | 5619442f37e7812b772661cb737ce78ab2313023 add bbb.txt
* | d5c2b697eba280a556fc96e71877568e3021b62a add aaa.txt
|/  
* 346ec94f12333e50cf78326ebe299b3976c845fb first commit

何か調べる時は前回リリース時のマージコミットを起点にdevelopの履歴を追えばわかるようになるので便利です

最初の頃はgit-flowとかGitHub Flowとかのブランチモデルを検討していましたが私がやってるくらいの小規模案件でやるにはこれくらいに留めといたほうが管理が楽で簡潔だと思ってます

ただ完全にオレオレ管理なので有識者の方からもっと良い方法があれば教えていただきたいです。

それでは良いバージョン管理をー

とっぴんぱらりのぷう

P.S.

git苦手だけど必要性は感じてるのでいつかは思い通りにコミットグラフを操作出来るようになりたいと思います

# xx/xx/xx 追加開始
~
# xx/xx/xx 追加終了

みたいなソース書くやつとか

資料_20210101.xlsx
資料_20210101_bak.xlsx
資料_20210101_最新.xlsx

みたいなファイル作るやつが普通に居るのでそういうの見る度にreset --hardで全て消えないかなとか夢想してます

ちなみに昔、設計書等も含めて全部git管理しようと提案はしましたが

「gitなんて外部に情報が流出してしまうからだめだ！」

と一応技術系のリーダーだった人に言われて終わりました

たぶんgithubと混同してたんだと思うけどそのまま新型うつ病で居なくなったあの人は本当に技術者だったんだろうか。。。

P.S.

Discussion