Git'te uzak dalları yeniden oluşturma

İnsanların klonlayabileceği ve üzerinde çalışabileceği uzak bir SVN deposunu yansıtmak için bir ara Git deposu kullanıyorum. Ara depo, ana şubenin yukarı yönlü SVN'den her gece yeniden temel almasını sağlıyor ve özellik dalları üzerinde çalışıyoruz. Örneğin:

remote:
  master

local:
  master
  feature

Özellik şubemi başarıyla uzaktan kumandaya itebilir ve beklediğim şeyle sonuçlanabilirim:

remote:
  master
  feature

local:
  master
  feature

Sonra uzaktan kumandayı izlemek için dalı yeniden kurmak:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

Ve her şey yolunda. Buradan yapmak istediğim, özellik dalını uzaktan kumandadaki ana dala yeniden oluşturmaktır, ancak bunu yerel makinemden yapmak istiyorum. Yapabilmek istiyorum:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Uzak özellik dalını uzak ana bilgisayarla güncel tutmak için. Ancak bu yöntem Git'in şikayet etmesine neden olur:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
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.

git pullhile yapar ama kaçınmak istediğim birleştirme taahhüdüne neden olur. İletinin bunun feature -> featureyerine belirtmesinden endişe ediyorum, feature -> origin/featureancak bu sadece bir sunum olabilir.

Bir şey mi kaçırıyorum, yoksa tamamen yanlış bir şekilde mi yapıyorum? Uzak sunucuda rebase yapmaktan kaçınmak kritik değildir, ancak rebase'deki herhangi bir birleştirme çakışmasını düzeltmeyi çok daha zorlaştırır.

Özelliğin bir kişi tarafından kullanılıp kullanılmadığı veya başkalarının bu özellik üzerinde çalışıp çalışmadığı anlaşılır.

Sadece sizseniz, itirazdan sonra itmeyi zorlayabilirsiniz:

git push origin feature -f

Ancak, başkaları üzerinde çalışıyorsa, birleştirme ve master'dan geri dönmemelisiniz.

git merge master
git push origin feature

Bu, birlikte çalıştığınız kişilerle ortak bir geçmişinizin olmasını sağlayacaktır.

Farklı bir düzeyde, geri-birleştirme yapmamalısınız. Yaptığınız şey, özellik dalınızın geçmişini, özelliğe ait olmayan diğer taahhütlerle kirleterek, bu dalla daha sonra çalışmayı daha zor hale getirmek - yeniden baslatmak ya da yapmamak.

Bu konu başına branş adı verilen makalemdir .

Bu yardımcı olur umarım.

Bu konuyu gündeme getirmiş olman güzel.

Git'teki bir sürü kullanıcının bilmekten faydalanacağı önemli bir şey / kavram bu. git rebase çok güçlü bir araçtır ve taahhütleri ezmenizi, taahhütleri kaldırmanızı sağlar. Ancak herhangi bir güçlü araçta olduğu gibi, temelde ne yaptığınızı bilmeniz gerekir veya bir şey gerçekten yanlış olabilir.

Yerel olarak çalışırken ve yerel şubelerinizle uğraşırken, merkezi depodaki değişiklikleri itmediğiniz sürece istediğiniz her şeyi yapabilirsiniz. Bu, kendi geçmişinizi yeniden yazabileceğiniz anlamına gelir, ancak başkalarının geçmişini yazamazsınız. Sadece yerel eşyalarınızla uğraşmak, hiçbir şeyin diğer depolar üzerinde hiçbir etkisi olmayacaktır.

Bu nedenle, taahhütleri bir kez ittikten sonra daha sonra yeniden pazarlamamanız gerektiğini hatırlamak önemlidir. Bunun önemli olmasının nedeni, diğer kişilerin taahhütlerinizi çekip çalışmalarını kod tabanına yaptığınız katkılara dayandırabilmesidir ve daha sonra bu içeriği bir yerden başka bir yere taşımaya (yeniden adlandır) ve diğer insanlar sorun yaşar ve kodlarını yeniden oluşturmak zorunda kalırlar. Şimdi 1000 geliştiriciniz olduğunu hayal edin :) Sadece gereksiz bir yeniden çalışmaya neden olur.

Yeninin featureüstüne yeniden bastığınız için master, yerel ayarlarınız featureartık bir hızlı ileri origin/featuredeğil. Yani, bence, bu durumda hızlı ileri kontrolü geçersiz kılmak gayet iyi git push origin +feature. Bunu yapılandırmanızda da belirtebilirsiniz.

git config remote.origin.push +refs/heads/feature:refs/heads/feature

Üstünde başka kişiler çalışıyorsa, origin/featurebu zorunlu güncellemeden rahatsız olacaklar. Yeni birleştirilmesi ile bu önleyebilirsiniz masteriçine featureyerine rebasing. Sonuç gerçekten hızlı bir ileri olacaktır.

--forceSeçeneğini kullanarak (ne yaptığınızdan emin olduğunuzdan emin olursanız) onay işaretini devre dışı bırakabilirsiniz git push.