特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
漫画の電子書籍は早くキャラ名地名のポップアップ機能を実装しろ
描いている本人はよく分かっているから不要なんだろうけど、キャラが多かったり場面転換が多かったり人間関係が複雑だったりすると固有名詞と絵がぜんぜん結びつかないわけよ。 いちいち戻って確認するのすさまじいストレスだし。 数話前の伏線でちょろっと出てきたようなやつの名前覚えているわけ無いだろ。 はやくタップしたら解説がでるような電書を標準にしろ。 それこそ電書の強みだろ。 まあ一番いいのはそんなものが不要な作品を描くことだが。 そう考えるとデスノートってすげえなあと思うわ。 自分から戻って読むことはできるけど、戻らなくても先にどんどん読み進んでいける。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
