Git push відхилено після відновлення функції гілки

Гаразд, я думав, що це простий сценарій git, що мені не вистачає?

У мене є masterфілія та featureфілія. Я займаюся деякою роботою над master, дехто над feature, а потім ще деякою master. Я закінчую щось подібне (лексикографічний порядок передбачає порядок комітетів):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

У мене немає ніяких проблем , щоб git push origin masterтримати пульт masterоновлюється, ні з git push origin feature(якщо на feature) для підтримки віддаленого резервного копіювання для моєї featureроботи. До цих пір нам добре.

Але тепер я хочу , щоб перебазувати featureна вершині F--Gфіксацій на господаря, так що я git checkout featureі git rebase master. Ще добре. Тепер ми маємо:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Проблема: в момент, коли я хочу створити резервну копію нового featureрозгалуженого розгалуженого шару git push origin feature, поштовх відхиляється, оскільки дерево змінилося через перезавантаження. Це можна вирішити лише за допомогою git push --force origin feature.

Я ненавиджу використання, --forceне будучи впевненим, що мені це потрібно. Отже, мені це потрібно? Чи має перебазування обов'язково означає , що наступний pushповинен бути --forceFUL?

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

Проблема полягає в тому, що git pushпередбачається, що віддалену гілку можна переадресувати до вашої локальної гілки, тобто вся різниця між локальною та віддаленою гілками полягає в локальному, який має в кінці нові нові коміти:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

При виконанні git rebaseкомісій D і E застосовуються до нової бази та створюються нові коміти. Це означає, що після повторної бази даних у вас є щось подібне:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

У цій ситуації віддалену гілку не можна переадресувати до локальної. Хоча теоретично локальна гілка може бути об'єднана у віддалену (очевидно, вона вам не потрібна в такому випадку), але як git pushвиконує лише швидкі злиття вперед, вона кидає і помиляє.

І що можна зробити --force, це просто ігнорувати стан віддаленої гілки та встановити її на зобов’язання, яке ти наштовхуєш на неї. Тож git push --force origin feature-branchпросто перекриває origin/feature-branchмісцевий feature-branch.

На мою думку, повернення функціональних гілок masterта примусовий переведення їх до віддаленого сховища добре, якщо ви єдиний, хто працює на цій гілці.

Замість використання -f або --force повинні використовувати розробники

--force-with-lease

Чому? Тому що він перевіряє віддалену гілку на наявність змін, що є абсолютно хорошою ідеєю. Давайте уявимо, що Джеймс і Ліза працюють над однією і тією ж галуззю, і Ліза підняла на себе зобов'язання. Зараз Джеймс відмовляється від своєї місцевої гілки і відхиляється при спробі натиснути. Звичайно, Джеймс вважає, що це пов'язано з перезавантаженням і використовує --force і переписав би всі зміни Лізи. Якби Джеймс застосував - примусово з орендою, він отримав би попередження про те, що існують зобов'язання, зроблені кимось іншим. Я не бачу, чому хтось використовуватиме --force замість --force-with-lease під час натискання після перезавантаження.

Я б замість цього використовував "checkout -b", і це легше зрозуміти.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

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

Одним з рішень цієї проблеми є те , що робити msysGit в перебазування злиття робить сценарій - після перебазування, зливає в старій чолі featureз -s ours. Ви закінчите графік фіксації:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... і ваш поштовх featureбуде швидким вперед.

Іншими словами, ви можете:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Не перевірено, але я думаю, що це правильно ...)

Це може бути, а може і не бути, що в цій гілці є лише один розробник, який зараз (після ребатування) не відповідає потоку / функції.

Як такий, я б запропонував використовувати наступну послідовність:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Так, нова галузь, це має вирішити це без сили, що, на мою думку, є головним недоліком git.

Мій спосіб уникнути силового натиску - створити нову гілку та продовжувати роботу над цією новою гілкою та після деякої стабільності видалити стару гілку, яка була перезавантажена:

• Випуск перевіреної філії на місцевому рівні
• Відгалуження від відновлюваної гілки до нової гілки
• Переміщення цієї гілки як нової гілки до віддаленого. та видалення старої гілки на віддаленому

Інші відповіли на ваше запитання. Якщо ви перезавантажите гілку, вам потрібно буде натиснути її.

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

Загалом, база даних добре працює для місцевого управління філіями. Віддалене управління філіями найкраще працює з явними злиттями (--no-ff).

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

Що не так з a git merge masterнаfeature гілці? Це дозволить зберегти роботу, яку ви мали, зберігаючи її окремо від основної галузі.

A--B--C------F--G
       \         \
        D--E------H

Редагувати: Вибачте, я не прочитав вашу заяву проблеми Вам потрібна сила, як ви виконували rebase. Усі команди, що змінюють історію, знадобляться--force аргумент. Це невдача, що не дозволить вам втратити роботу (стара Dі Eбула б втрачена).

Отже, ви виконали те, git rebaseщо зробило дерево схожим (хоча частково приховане як Dі Eбільше не знаходиться в названій гілці):

A--B--C------F--G
       \         \
        D--E      D'--E'

Отже, намагаючись просунути свою нову featureгілку (з D'і E'в ній), ви втратили б Dі E.

Для мене такі легкі кроки працюють:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Зробивши все вище, ми можемо також видалити гілку myFeature, виконавши наступну команду:

git push origin --delete myFeature

Наступні роботи для мене:

git push -f origin branch_name

і він не видаляє жодного з мого коду.

Але, якщо ви хочете цього уникнути, то можете зробити наступне:

git checkout master
git pull --rebase
git checkout -b new_branch_name

тоді ви зможете вибрати всі свої зобов’язання до нової гілки. git cherry-pick COMMIT ID а потім натисніть свою нову гілку.

Як ОП розуміє проблему, просто шукає кращого рішення ...

Як щодо цього як до практики?

• Увімкніть фактичну галузь для розвитку функцій (де ви ніколи не перезавантажуєте та не натискаєте, тому ваші колеги-розробники функцій вас не ненавиджу). Тут регулярно з’єднуйте ці зміни з основного. Історія Мессьє , так, але життя легко, і ніхто не переплутається в його роботі.

• Майте другу гілку для розробки функцій, де один член команди команди регулярно відсуває всі функції, які дійсно перезаряджаються, дійсно вимушеними. Так майже чисто базується на досить недавньому майстер-зобов'язанні. Після завершення функції натисніть на цю гілку зверху головного майстра.

Для цього методу вже може бути назва шаблону.