Гілка Git розходилася після ребазування

112

Я повернув місцеву гілку, яка вже була натиснута.

Git радить, що моя філія та віддалений відділилися і що:

"і мають 109 та 73 різних передач відповідно"

Чи вирішить це натискання на мою гілку - тобто це варто очікувати після перезавантаження?

git

У мене те саме питання. Чи можемо ми сказати, що "правильний спосіб зробити" - це відновити локальну гілку і лише потім натиснути?

— Mher Didaryan

154

Коли ви перезавантажуєте філію, вам потрібно переписати комісії для будь-яких комісій, що знаходяться вище комітетів у гілці, на яку ви перезаписуєте. Це пов’язано з тим, що однією з властивостей комітету є його батько (або батьки). Під час повторної бази даних ви змінюєте батьківську найстарішу локальну комісію у своїй гілці - і, таким чином, змінюєте хеші фіксації всіх ваших локальних комісій, оскільки це змінює бульбашки вгору через коміти.

Оскільки ви вже натиснули гілку, вам слід було б об'єднатись у вихідну гілку, а не відмовлятися від неї. Можна "примусити" натиснути свою нову гілку (використовуючи -fпрапор), але звичайний поштовх не працюватиме, оскільки цілісність історії гілок буде порушена. Якщо ви співпрацюєте з іншими людьми на цій гілці, натискання - це погана ідея, оскільки це призведе до того, що інші співробітники дуже заплутаються, коли їх історія раптом не збігається.

TL; DR - Якщо ви не співпрацюєте, натисніть гілку за допомогою push -f. Якщо ви є, відновіть гілку до попереднього стану та замість неї з’єднайте джерельну гілку.

— Джейсон Лебрун
джерело

1

"Оскільки ви вже натиснули гілку, ви повинні були об'єднатись у вихідну гілку" - чому це так?

— хаммет

1

Перше речення @HamiltonVerissimo Джейсона: "Коли ви перезавантажуєте філію, ви повинні переписати комісії для будь-яких комісій, що знаходяться вище комітетів у гілці, на яку ви повторно використовуєте". Навіть незважаючи на те, що зміни, записані у коміксах "вище", мають однаковий логічний зміст, вони застосовуються до іншої бази та тому є різними комітами з різними хешами. Якщо інші розробники працюють із заздалегідь відновленою гілкою, то виконання git push -f буде вкрай руйнівним для їх робочого процесу. Таким чином, оскільки ця галузь була перенесена на загальнодоступне джерело, він повинен був об'єднатись.

— awolf

4

Ви можете також скористатися push -for-with-lease, якщо ви не впевнені, чи хтось ще щось щось натиснув.

— Консоль

1

@ jason-lebrun Чи не є недоліком об'єднання змін у верхньому напрямку, що ви можете перезаписати власну роботу без попередження? Чи виявляються конфлікти злиття так само, як і при повторному оновленні? Наприклад, якщо я видаляю розділ з файлу у своїй гілці, оскільки він більше не потрібен, але хтось інший вніс тривіальну зміну в той самий розділ у верхній частині потоку, як-от видалення пробілу чи деяку глобальну дію пошуку / заміни, не буде злиття, що поверх моєї гілки замінити моє видалення їх тривіально зміненою версією?

— Кріс Блум

1

Чи злиття іншої гілки з вашою не погана ідея? Наприклад, об'єднання майстра в галузь функцій - чи це не створить для цього новий комітет? Чи це не призведе до додаткових комісій після того, як ця галузь функції, якщо згодом об'єднається в master?

— Росс

55

Всі ваші коммітов змінилися ідентифікатори, так що витоку не дійсно розходяться.

Щоб вирішити вашу проблему, вам потрібно перезаписати віддалену гілку:

git push -f origin experiment

http://git-scm.com/book/ch3-6.html

Пояснення:

Подивіться, як на цьому зображенні C3 ставиться не як C3 після перезавантаження, а як C3 '. Це тому, що це не зовсім C3, але він має всі свої зміни коду.

База даних

На цьому іншому зображенні ви отримуєте картину того, що бачить ребазація, коли задіяний пульт, і чому відбувається переадресація.

розходяться і поштовхують

У будь-якому випадку, після того, як ви зробите примусовий натиск, він скаже вам, що він зробив (оновлення сили), ви повинні бути в порядку до цього моменту.

Перевірте посилання вгорі та знайдіть "git push --force". Ви побачите більш детальне пояснення.

— міморалія
джерело

3

Так. Я думаю, це вирішує проблему. Але примусовий натиск може не працювати, коли ви працюєте в команді, коли ваш поштовх може замінити будь-яку недавню роботу, яку підштовхнули інші. Маю рацію?

— Харі Крішна Ганджі

Це може не мати бажаних ефектів. Переконайтеся, що ви з’єднали зміни "швидко вперед", перш ніж робити ребазу.

— mimoralea

1

Я мав успіх із розбігом баз даних для того, щоб натиснути, зробивши наступне:

git checkout mybranch
git pull
git push origin mybranch

Тяга вирішила розбіжність.

ДО ПЕРЕД тяг

Your branch and 'origin/mybranch' have diverged,
and have 2 and 1 different commit(s) each, respectively.

PULL вихід

Злиття здійснюється рекурсивно. mypath / myfile.py | 12 +++++++++++ - 1 файл змінено, 11 вставок (+), 1 видалення (-)

ПІСЛЯ потягніть

Ваша філія випереджає "походження / мій галузь" на 3 коміти.

ПІСЛЯ ПУШКУ

mybranch 3 напередодні гілки, все ще є відкрите запит на злиття запиту на додавання до історії фіксації Об'єднання гілки mybranch віддаленого в mybranch

Я припускаю, що це, мабуть, те, що робить натиск сили, і я не підтвердив це.

Як уже говорили інші, уникайте перезавантаження, якщо у вас вже є запит на відкриту тягу. Я наводжу цей приклад як щось, що працювало на мене.

— zerocog
джерело

1

Це можна виправити без силового натискання, повернувши цільову гілку у вашу поточну локальну гілку, переключившись на вашу цільову гілку, а потім перезапустивши локальну гілку в ціль. Це не розходиться, оскільки комісії, які можуть бути відсутні, додані і більше не потрібно їх створювати. Приклад для більш легкого пояснення:

розвивається основна галузь
Ви оформили нову функцію філії / doing_stuff
Член команди підштовхує нове зобов'язання розвиватися

Якщо ви НЕ оновили свою галузь розробки, тоді "git checkout development" && "git rebase function / doing_stuff" буде працювати правильно, оскільки жодних комісій не додано з моменту оформлення замовлення. Однак, якщо ви перевірили розробку та зняли нову команду, ви побачите це розбіжність, якщо ви спробуєте перезавантажитись із-за того, що побачите нове зобов’язання. Легке виправлення без силових натискань (як правило, не є хорошою ідеєю в командному середовищі):

git checkout функція / doing_stuff
git rebase розвиватися
git checkout розвиватися
функція відновлення git / doing_stuff

Поновлення з кроку 2 вносить відсутні функції для виконання у функцію / doing_stuff, тому коли крок 4 приходить разом із цим, він є актуальним і не потрібно створювати нову комісію для зміни.

Це рішення, яке я знаю, працює, тому що я просто зіткнувся з цим і зробив вищезазначені кроки, щоб успішно підштовхнути розвиток без примусу. Я працюю в команді з понад 50 розробників, тому забороняється змушувати натискати що-небудь, крім моїх власних тестових гілок, тому мені довелося знайти рішення.

— Кріс
джерело