GithubFlowを使う上で心がけているコミット/プルリク/レビューの考え方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GithubFlowの導入をして、実際にやっていくにあたり チームごとにルールを決めたり、プルリクエストの方法を考えると思うのですが チームとしてではなく、自分自身の中で守ってはいきたいと思う 個人レベルでもできる心構えを『コミット』『PullRequest』『レビューコメント』の 大きく3つでまとめてみました。 コミット コミットコメントは丁寧に コミットに関してはコード修正に直接結びつく部分なので その修正に関しての概要を手短に述べるようにする。 ただし、漠然とした汎用的な言い回しになり過ぎないように注意する。 また大前提としてGi
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
