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

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

Однак це призводить до того, що мені часто доводиться робити git push --forceвіддалене сховище після ребави, дії, яке, як правило, нахмуриться. Або як говорить пов'язана сторінка github:

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

Чи існує (загальновизнана) політика, яка вирішує цей конфлікт?

Чому це не дублікат « Чи так суттєво важливий git« Золоте правило звільнення »?

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

Ключове питання, яке потрібно задати собі:

• Чи зберігаєте ви свою віддалену гілку після об'єднання назад у майстер?

Якщо ви видалите свою віддалену гілку функції після об'єднання в головну, ви вже втрачаєте історію. Якщо припустити, що ви скошуєте / перезавантажуєте відділення перед тим, як здійснити об'єднання / PR, ви втратите цю історію. У вашому випадку все ваші сили натискання дозволяють використовувати github як резервну копію.

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

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

Здається, що на цю гілку одночасно просуваються кілька людей. Це означає , що ви зробити піклується про історію на гілці.

Що ви можете зробити замість своєї проміжної роботи, це створити вилку цієї гілки. Ви можете натиснути на це, а потім перезавантажити всі свої зобов’язання в одне зобов’язання перед об'єднанням, тому коли ви об'єднаєте їх у свою галузь функцій, у вас є лише 1 фіксація (з перезавантаженою історією всієї вашої гілки).

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

Завжди переглядайте нову гілку

Маючи безладну гілку some-feature, переставте її на нову гілку. Напр

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Потім some-feature-rebaseпереглянули та інтегрували.

Проблема: Великий недолік тут полягає в тому, що, строго кажучи, вам потрібна нова гілка для кожного ребазу. (Ви можете мати кілька знижок, якщо внесете зміни, наприклад, після перегляду коду)

Використовуйте git push --force-with-lease

Я щойно дізнався про git push --force-with-leaseальтернативуgit push --force , якій

відмовляється оновлювати філію, якщо ми не очікуємо такого стану; тобто ніхто не оновлював гілку вище за течією.

Проблема : Це, здається, покращує ситуацію, коли ми використовуємо просто --force, але все ще є деякі застереження, особливо, коли я роблю git fetchзамість цього git pull, який оновлює наші локальні гілки вище за течією, --force-with-leaseзадумавшись про те, що на пульті дистанційних змін не було внесено відділення.