マージできるかどうか。含む新しいコミットグラフ。漠然とした質問ではありますが、私も感ずることがあるので要所要所を回答します。あなたの組織のものさしは、何でしょうか。ここを何でも良いので定義しましょう。それを改善する手法を考えます。私はこれまで他のソフト開発の職場で働いたことがなく「普通はこうする」や「最近はこういう風に開発する」のような勘所がわからないため、この方向で良いのか、更にもっと良い方法があるのか不安です。不安があるということは、目的が不明確またはそれを達成できる裏付けが足りないということです。いざ説明しようにも説得力が欠けてしまいます。「普通」や「流行り」で通用するなら、とっくに「普通」で「流行り」の開発スタイルになっているはずです。運用ルールについて※かなり原理によった考え方ですので、本来はプロダクトの性質やチームの状況によって柔軟に進めてください。2点勘違いがあります。releaseブランチで安定化作業を行います。質問をみると「動作確認」というおそらくリリース前の作業があると推測されます。releaseブランチを作成して、ステージング環境にアップロードしてバグフィックスを行いましょう。使ったソースコードを版管理をするには?適切な.gitignoreを追加してプロジェクトに必要のない一時ファイルを無視すること。以下のURLのものをとりあえず入れておけばいいと思います。addする際にmetaファイルを忘れずに追加すること。この二点が最低必要だと思います。構成になっているので、自分のリポジトリ内で作業するともちろん正しくビルド出来ません。等は書き換えず対象ユーザのリポジトリ内で作業すべきかと思います。実行すると過去のコミットが圧縮され、容量を減らすことが出来ます。設定しておく事で定期的に実行しなくても自動で実行してくれる様になります。する方針を取られるのが良いと思います。コマンドの使われ方です。ディレクトリが既に存在していると、件のような実に気持ちの悪いエラーと共に、処理が止まります。