git の運用指針 - Cube Lilac

ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ

[ruedap]

featureブランチをpushした以降にdevelopブランチでrebaseしちゃうと、-fオプション付けないとpushできなくなると思うけど、この場合はどうしてるんだろう

[borerere]

わかりやすくまとまっている

[inureo]

[branchining

[ryonext]

rebaseとpullの違いよくわかってなかった。

[TsutomuOnoda]

git の運用指針 - Life like a clown

[vivit_jc]

masterにどんどんぶっこむクソ運用しかしてないのでもっと勉強する

[shuzo_kino]

赤の他人に引き継ぐとき苦労したので、次からこのルールに従う=>従ったら意思疎通楽になりました。超オススメ

[new3]

gitで作業するときのブランチ管理方法の考え方の１つ。参考にする

[meets623]

git の運用指針 - Life like a clown

[Magicant]

checkout feature/<ticket> の後に merge feature/<ticket> する意味が分からん / この記事の rebase の使ひ方は怪しい

[zentarou]

不要なファイルをaddしないのは基本だけど、add -pで不要な変更をaddしないのも捗るぜ

[auient]

こういう運用についての話って参考になる

[s_z_ki]

git

[vid]

最近は git の記事が増えてきて、いろいろと参考に出来て楽だなぁ（＾＾；；

[atsushifx]

そういや、Git前提で構成管理をきちっとやるための説明を本やWebで見たことない気がする。後でさがしてみるか