Чому б не здійснити невирішені зміни?

У традиційному VCS я можу зрозуміти, чому ви не зробили б невирішені файли, оскільки ви могли зламати збірку. Однак я не розумію, чому ви не повинні здійснювати невирішені файли в DVCS (деякі з них фактично не дозволять вам робити файли).

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

Можливість вчиняти під час процесу злиття має ряд переваг (як я бачу):

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

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

То чому ж вчинення невирішених файлів нахмурюється / перешкоджає? Чи є якась причина, крім традиції?

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

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

Я найбільше знайомий з Git, тому я відповім на цю точку зору.

Я не бачу причини, чому ви або будь-який хороший VCS хотів би дозволити введення файлу без виправлення, особливо якщо це був код. Вам потрібно зберігати сховище у постійному стані, і те, що ви припускаєте, порушило б атомність. Багато VCS фізично змінюють файл, щоб показати, де конфлікти - Git, SVN та CVS використовують маркери типу >>>> <<<<. У VCS з атомним рівнем сховищ здійснює і зливається, ви просто створили б вузол, який не має сенсу ні для кого, крім вас. У розробці програмного забезпечення ваш проект не міг побудувати. У документі групи ніхто не знає, які зміни є правильними.

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

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

1. Фактичні зміни об’єднання є в історії. Для чого потрібна додаткова інформація? DVCS дуже добре стосуються обмеження конфліктів обмеженими районами. Щойно ви виберете, який набір змін зберегти, порівняння копії вузла злиття з попередньою копією дасть вам саме це.
2. Якщо злиття було дуже великим, ви можете робити періодичні комісії. Це важлива проблема, але ви ніколи не повинні потрапляти сюди в першу чергу. Гілки повинні постійно тягнути до змін вгору за течією, щоб цього ніколи не відбулося. Інструменти на кшталт rebaseабо збирання вишні одночасно можуть також допомогти вам у деяких ситуаціях.
3. Якщо ви помилилися, було б набагато простіше відкати (без повторного повторного злиття). Дивіться вище - ваші конфлікти не повинні стати таким незмінним.

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

Головний мій досвід - Mercurial, хоча я також використовую git епізодично.

Mercurial не дозволяє вам робити невирішені файли, це просто відлякує вас. Те ж саме займайтеся натисканням, перш ніж тягнути зміни, яких у вас немає.

Все, що вам потрібно зробити в Mercurial - це, як тільки ви матимете файли так, як ви хочете зробити їх:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

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

Якщо ви хочете натиснути, не тягнучи (і, отже, зливатися з іншими змінами), зробіть як джедаї :

hg push --force

Наступний хлопець, який витягне, отримає +1 голову (каламбур не призначений)

Я впевнений, що є спосіб зробити те ж саме з Git (хоча це, мабуть, більш складно).

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

Чесно кажучи, я не розумію, чому інші цього не роблять, або git не виконує цього.

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

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

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

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

Робити багато з відкритим кодом з git, найбільше розчарування для мене було отримання наполовину завершеного коду, накладеного на репо, та спроби зробити збірку, але не вдалося, бо хлопець зробив половину роботи і сказав: "Я зараз зайнятий , Я закінчу це через тиждень ». Тож я б у кінцевому підсумку мусив його зламати (що би дратувало хлопця), або знадобився час, щоб закінчити і повністю інтегрувати його.

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

Не будьте рабом своїх інструментів.

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

Однак не слід штовхати зламаний код за течією.

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

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

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

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