Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
