Uni-Q blog

うにきゅう ぶろぐ

デザイナーのブランチ運用について考える

photo by toolmantim

エンジニアベースのブランチ運用

以前、Git使ってた頃は、エンジニアベースのブランチ運用で、エンジニアがシステム実装してるブランチから、デザイナー用のブランチを派生させて、そこにデザインちょこちょこ実装し…

git pull --rebase origin/branch_a

みたいな、rebase もしくは merge 。

デザインベースのブランチ運用

機能A、機能B、機能Cの開発。
エンジニアは、それぞれのリリースに影響しないように、機能A、機能B、機能Cの実装を別々のブランチで行う。
エンジニアは機能A→機能B→機能Cという順番で実装予定だけど、予定はあくまで予定なので、何を先にリリースするか分からない。

でもデザインは、全体のデザインからの部分的なデザイン実装なので、機能A、機能B、機能Cと別々に実装してたら、流れの悪い・統一感のないデザインになっちゃったり、それぞれのブランチにcommitしちゃって、CSSや画像が重複しちゃったりする。どうしようか。

さらに、見積もり時間を計算したら、どうやらデザイン作業が先行しそうな予感だ。

エンジニアと同じような順番で機能Aから実装するのではなく…、
エンジニアと同じブランチで作業する前に、機能A、B、Cで共通で使うCSSや画像を考えて用意する必要がある。(デザインやCSSの設計するタスクが必要)

デザインベースのブランチを作成して、そこに共通部分を実装する。push。
それを、エンジニアの機能A、B、Cにmerge して、それぞれのブランチでデザイン実装を行う。