More than 5 years have passed since last update.

Git初心者がCommitの粒度とかを考えた話

Posted at 2019-09-12

##はじまり
###ある日
「…今日も作業が終わったし、進んだ分をCommitしよか」
「お、ランキングに面白い記事があがっとるし、休憩がてら見てみよか」

「ほえー」
「gitのcommit粒度もチームで開発していく上で重要なんやな…」

##リポジトリを見てみると…
「せや、さっきcommitしたgitの履歴見てみよか」
「gitていうたけどgithubの履歴なんは勘弁な」

…
……
………
「なんやこれ、ざっくりしすぎや」
「何してるかは辛うじて読み取れるけども、内容に関して直感的に読み取ることができないやないか…」

「このままじゃあかん…なんとかせな…」
##ルールを考える
「とはいえどうしたらええんやろか…」
「ワイにはハスケル子ちゃんはおらんしな…自分で考えるしか道はないんや…」
「ただ単にルールを決めても、区別がつかんとあかんきがする…」

「せや、変数みたいに接頭詞をつけることで意味を固定化できるかもしれん」
「慣れたら不要かもしれんが、慣れんうちは意識付ける目的でやってみよか」

「ついでに、実際に作業したときのことを考えてみよか」
「ちなみに今回はVue.jsを使ってやってみるで」
###New
「Newはファイルの新規作成時に使う用やな」
「ライブラリとか参照とかは記述しておくし、最低限の様式は整えるけど、コーディングは一切されてないんやな」
####例

NEW - 検索フォーム
NEW - TABウィンドウコンポーネント

sample.vue

<template>
</template>

<script>
export default { 
}
</script>

<style scoped>
</style>

sample.spec.js

import { mount } from '@vue/test-utils'
import Sample from '@/components/sample.vue'

describe('sample.vue',()=>{
    
})

「コードとしては最低限の状態なんやな」

###ADD
「こっちは作ったファイルになにか変更を加えた時に使うんやな」
「commitするときは、機能ごとや関数毎とか変更箇所を1個に絞るのが肝やな」
「あんまりごっちゃ混ぜでcommitすると、何の目的で変更したかわかりにくいしな」

####例

Add - NewMethodを追加
Add - NewMethodに非同期処理を追加
Add - HogeHage変数名をHageyarouに変更

「ボタンとクリックしたときのイベントを追加したいときはこうやるとええんやろか」

sample.vue

<template>
    <button>
    </button>
</template>

「まずはButtonタグだけの追加やな」
「次にイベントの追加やな」

sample.vue

<template>
    <button @click='onClick>
    </button>
</template>

<script>
export default { 
    methods:{
        onClick:()=>{
            //処理
        }
    }
}
</script>

「最後にイベントとメソッドを作ってコミットなんやな」
「今回は短い処理を想定してるからこれでええんやろうかな」
「長くなったりした場合にはここから更に処理とかを分割してわけていくべきやろな」

###REMOVE
「逆に削除するときのやな」
「これもADDと同じで、削除するときは一気にやるんじゃなくて、機能毎に順番に消していく方針やな」
「ただ、ファイル規模だと一気にやってもええんやろうけど」

####例

Remove - NewMethodを使わなくなったため削除

###BUG_FIX
「不具合対応用やな」
「変更箇所は他のと同じ感覚でやっていくんやな」
「ブランチ側でBUG対応のを作る運用もあるし、もしかしたらいらんかもやな」

####例

BUG_FIX - InputでEnterキーを押してもイベントが発生しない

##ボツ
「色々考えてた結果、途中でボツになったやつやな」
「なぜボツにしたかも残しておくことで、途中どういうふうに考えたかの思考を残しておこか」
###WORKING
「NEWのあとの作業で使う予定やったやつやな」
「そもそもWORKINGて作業工程が何やねんなのと、ADDとどう違うねんてなったんやな」
「結局ADDでええやんてなった結果ボツやな」
###UPDATE
「当初は既存箇所変更をUPDATEに、新規追加をADDにするようにしようと思ってたんやな」
「分割するほどの意味があるかと言われればあやしかったからボツなんやな」
「ただ、後々復活もありかなとは書いた時は思ってるんやな」
###FIX
「作業が終わったときに、終わったことをCommitでもわかるようにしようと思ってたんやな」
「ただし、それならプルリクで知らせるほうがいいやないか！てことでボツになったんやな」

##終わり
「自分なりにやけど考えてみたけど、ええのができたな」
「ADDあたりはまだ不安やけど、ここからさきはやってみて感覚を掴んでいきたいんやな」
「ワイ記法も初めてやけど、なんとか記事にできたのもよかったんやな」

「許していただいたやめ太郎さんには感謝しつくしてもたりひんで…」

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up