2016-08-22 15 views
2

私の会社はbitbucket-Gitのコードをホストしました。私たちが働く方法は、すべての問題のブランチを作成し、そのブランチで個々の人が作業することです。作業が終了すると、プルリクエストが発生します。 PRを呼び出す前に、彼はマスターブランチでコードをリベースします。チームの他の人が彼のPR &を承認して承認します。 PRが承認されると、同じ個人がマスターブランチとマージしますbitbucket - マージされたブランチのコミットを見ることができません。

私は6月2日にブランチを作成しました& PRは6月14日にマージされました。ブランチには3つの異なるファイルで3つのコミットがありました。続いて、6月26日に他の開発者ブランチがマージされました。彼はまた、2つのファイルに取り組んでいます。今月以上に、私がファイルの履歴をチェックするとき、私はそこに私のコミットを見ない。私が変更した3つのファイルのうち、ただ1つのファイルの変更だけが&であり、正しいコミット番号を示しています。他の2つのコミットはファイル履歴に表示されません。私は推測することができます、私の変更はオーバーライドされているが、ファイルのgitの履歴は、コミットを表示する必要があります。

どのように起こることができるか、誰もが考えていますか?私はgitの歴史の中で特定のファイルに対してどのようにコミットが消えたのかを意味します。

おかげ Aniruddha

+0

間に強制的なプッシュはありますか? – MaNKuR

+0

@ MaNKuR:おそらくはい。私は3つの異なる場所で働いているので、明確な答えはありません。 – Aniruddha

答えて

1

当社は、同様のプロセス使用しています:

  1. を私たちは、問題の支店で働く
  2. シニアのDevレビューのBitbucket
  3. をプル要求を作成し、承認する(またはしません)
  4. マージ競合が存在しない場合、マージする
  5. ther eはマージ競合です。開発者が解決する必要があります。

注意ここでは、リベースではなくマージと言います。リベースは、不注意のために危険に満ちている。リベースすると、既存のコミットを破棄し、類似しているが異なる新しいものを作成します。あなたがBitBucketにプッシュして他の人がプルダウンしてそれらをベースにして作業した後、それらのコミットをgit rebaseで書き直してもう一度プッシュすると、同僚は作業を再マージしなければならず、プルしようとすると、彼らの仕事はあなたのものに戻ります。おそらく、これらの行に沿った何かが、あなたの支店が出ている間に同僚が仕事を再建し、あなたのコミットを粉砕したところで発生しました。 git logを賢明に使用してこのコミットを解くことで、どのコミットがどれであるかを知ることができます。

今後、リベースをマージすることをお勧めします。上記で言及したように、プルリクエストにマージ競合がない場合、何もしないでください。存在する場合、それらを解決するプロセスは次のとおりです。

+0

提案リベース対マージありがとう。正確に何が起こったのかを説明することは可能ですか?それをどうすれば確認できますか? – Aniruddha

関連する問題