読者です 読者をやめる 読者になる 読者になる

09

git の branching 戦略とか以前

いまのプロジェクト、ソースコードはgitで管理してて、ブランチ戦略のためにgit flow入れているんだけど、どうも複数の作業をごっちゃにして進行してしまいがちになる。ある機能に着手しようとして、機能ブランチを切り、がりがりとコード書いて、何度かコミットしたりもしているうちに、なんか違うチケットの事が気になる事がある。この作業する前にあのチケットの課題クリアしておかないと後から手戻りになるんじゃね?的なものだ。そうするとそっちを先に解決しないといけないと思い、その作業に着手してしまってある程度たってからしまった、ブランチ切るの忘れた、と思う。別にgitでその辺間違ってもなんとか取り回せるんだけど、なんかうまく作業できてる感じしない。し、こういう場合後からコミットログがどう見えていたらうれしいのかもよくわからない。

最初に取りかかった作業と後から着手してしまった作業は別物なのだから、それぞれ別のブランチであるべきなのだろうか。あくまで別のブランチを作成して、後でリベースするとかマージするとかした方が良いのか。後から着手してしまった作業というのはこれも機能でいえば多くの作業があるのだけど、最初に取りかかった作業ではその一部しか必要としていない。単純に作業の順序を入れ替えろという事なのかもしれないけど、最初からそんな事わからない。別な機能ブランチを作れば良いかもしれないけど、たまたま今必要になっているのはフォルダ名の変更だ。フォルダ名を変更するといろいろな箇所の参照パスが変更されたりするが、何より物理的なファイルの位置が変わってしまうので変更がちゃんとトラッキングされるのか気になる。

先ず機能ブランチAをきった。色々作業して何度かコミットしたりした。で、ここで機能Bで行う予定だった作業に着手しなければ、ブランチAでの作業に手戻りが出そうな事がわかった。しかたないので機能Bのために機能ブランチBを切る。で、ブランチBで作業する。これはディレクトリツリーの変更を伴うものだ。で、一通り変更が終わった後でブランチAでブランチBの変更を取り込めるのだろうか?