Звільнення та те, що означає "повторне звільнення"

Часто кажуть, що не слід перезавантажувати зобов’язання, які ви вже натиснули. Що може означати це?

Книга ProGit має гарне пояснення .

Конкретну відповідь на ваше запитання можна знайти в розділі під назвою " Небезпеки звільнення ". Цитата з цього розділу:

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

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

• Сторінка gitworkflowsлюдини: Див. "Об'єднання вгору" та "Теми гілок"
• ProGit: Див. Розділ " Приватна керована команда "
• Блог Jarrod Spillers: Див. " Git merge vs git rebase: Уникнення пекла Rebase "

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

він має чотири коміти на головній гілці, і кожен коміт має ідентифікатор (у цьому випадку a, b, c і d). Ви помітите, що d на даний момент є останньою коміткою (або HEAD) головного відділення.

Тут у нас є дві гілки: майстер і моя. Ви можете бачити, що і master, і моя гілка містять символи a і b, але вони починають розходитися: master містить c і d, тоді як my-гілка містить e і f. b, як кажуть, є "базою злиття" моєї гілки порівняно з головним - або, звичайно, просто "базою". Це має сенс: ви бачите, що моя філія була заснована на попередній версії master.

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

Коли ви перезавантажуєте, git знаходить основу вашої гілки (у цьому випадку, b), знаходить усі коміти між цією базою та HEAD (у цьому випадку e та f) та повторно відтворює ці коміти на HEAD гілки ви відмовляєтесь (у цьому випадку майстер). Git фактично створює нові коміти, які представляють, як виглядають ваші зміни на вершині майстра: на діаграмі ці коміти називаються e ′ і f ′. Git не стирає ваші попередні зобов’язання: e і f залишаються недоторканими, і якщо щось піде не так з перезавантаженням, ви можете повернутися до того, як було раніше.

Коли багато різних людей симулюють роботу над проектом, запити на витяг можуть швидко застаріти. "Застійний" запит на витяг - це той, який більше не відповідає сучасній основній лінії розробки, і його потрібно оновити, щоб його можна було об'єднати в проект. Найпоширеніша причина, по якій запити на витягнення застаріли, пов’язана з конфліктами: якщо два запити на витягування модифікують схожі рядки в одному файлі, а один запит на витягування об'єднується, запит про витягнення тепер буде конфліктом. Іноді запит на виклик може залишатися незмінним без конфліктів: можливо, зміни в іншому файлі в кодовій базі вимагають відповідних змін у вашому запиті на витяг, щоб відповідати новій архітектурі, або, можливо, гілка була створена, коли хтось випадково об'єднав невдалі тестові одиниці тесту з майстер відділення. Незалежно від причини,

Звільнення переписує історію. Якщо про цю історію ніхто не знає, то це прекрасно. Якщо ж ця історія загальновідома, то переписування історії в Git працює саме так, як це відбувається в реальному світі: вам потрібна змова.

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

Зауважте, що є приклади успішних змов: puфілія сховища git Junio ​​C. Hamano (офіційне сховище Git SCM) часто повторно базується. Це працює так, що майже всі, хто використовує pu, також підписалися на розсилку розсилки розробників Git, а той факт, що puфілія перезавантажена, широко розголошується у списку розсилки та веб-сайті Git.

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

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