2011-10-17 7 views
4

職場では、各開発者は自分の開発ブランチを持っています。ブランチ= dev_name_of_employee。 IE。 dev_jon現在のGitブランチを持ち、その内容をマスターに "リセット"します

dev_jonには、テストやデプロイメントの準備ができていない新しい機能があります。そのため、別のブランチを作成してstaging_jonという名前で新しい機能を追加しました。

もう1つの機能を使い、dev_jonにmasterの内容を含める必要があります。マスターのものに戻ることの種類。

dev_jonとそのリモートブランチを削除せずにマスターから再作成する方法はありますか?すでに押し込まれているので、これらの変更はすべてステージングできません。

また、各従業員が開発中に一貫した支店で働くようにするより良い方法がありますか?

+4

開発者に個人的なブランチを与えないで、機能ごとにブランチを使用してください。こうすることで、開発者は「支社や鉱山」を問わずに支店を共有することができます。 –

+0

これを投稿して以来私が得た経験から、開発者名による分岐は悪い考えです。 'bug/3452-table-search-broken'や' feature/89756-add-check- 'のような短い記述が付いているチケット管理システムに参照されるチケットIDは、 「もの」。 – Jon

答えて

9

dev_jonで、あなたが行うことができます:

git reset --hard master 

は、関連する/直接適用できないかもしれませんが、あなたはGitHubの流れを見ることができます:私はあなたの現在のモデルは本当に理想的だとは思わないhttp://scottchacon.com/2011/08/31/github-flow.html

+0

GitHub Flowは、開発者ごとに一貫したbranch_name、つまりdev_jonを保持しないことを提案しますが、新しい機能ごとに新しいブランチを作成します。それはおそらくどのようにする必要があります。悪いことに 'git reset -hard master'を試して、それが私の望むことをするかどうかを見てください。ありがとう。 – Jon

1

開発者は複数の機能を同時に開発できなければならないため、開発者一人あたりのブランチが最も柔軟ではありません。とにかく、私が想定しているdev_jonが追跡しているの原点/マスターどうなるのか、ここであなたの状況で:

git reset --hard origin/master 

これはまた、あなたがdev_jon枝の上に現在あると仮定しています。

は、あなたがあなたのdev-jonブランチがマスターと同じであることを取得するには、ハードリセットを実行することができます

+0

ええ、私は理想的ではないと思います。 – Jon

1

、それがお役に立てば幸いですが、あなたは、あなたの新しい仕事を公開するために来たときに注意する必要があります。リモートブランチorigin\dev_jonは古い機能となり、あなたがプッシュしてくるときには、次の

! [rejected]  dev_jon -> dev_jon (non-fast-forward) 
error: failed to push some refs to '/tmp/example' 
To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 

のような警告がlarsmansにより示唆されるように機能ブランチを作成することを検討して取得します。

関連する問題