Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO

開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid

[yarumato]

“tangled commitなくせ。ユニットテスト通る単位でcommitしろ。大きなPullReqはコードレビュー重労働化->小さな変更を積み重ねて。PullReq概要欄に関連issue書け。UI変更は変更前と後のスクショ貼れ。mergeはレビュー必須”

[tkmkg8m]

複数の意図/目的を持つ変更はダメ。テストが通る単位でコミット。大きな1コミットより小さなたくさんのコミット。

[braitom]

GitHubでチーム開発を行うときのガイドラインについて。commit時、PR時、merge時に分けてシンプルにまとめられている。

[tengo1985]

けっこう近い運用だけどちゃんとガイドラインを制定できてない

[hdampty7]

プロダクツにもよるんだけど、いい感じな気がする。

[nakag0711]

他人が何作ってるのか知らないのに突然レビューだけ依頼されても困るんだよね。全てを知っている人がいる段階の製品ならいいのかも知れないが

[newnakashima]

こういうのが普通にある文明化されたプロジェクトに参加したい

[shoh8]

適度でよさそう。使おうというか暗黙知を共有知に変える

[clash_m45]

まとまっていて良い[github][git][guideline]

[sogaoh]

適度でいいな、と思った。劉邦の法三章、みたいな。

[peketamin]

“tangled changes というのは複数の意図や目的を持つ変更のことです。”

[tolkine9999h]

こういうガイドライン凄く良い。チーム内の指標になるしベースにしてカスタマイズできる。