Головні болі з використанням розподіленого контролю версій для традиційних команд?

Хоча я використовую і люблю DVCS для моїх особистих проектів і цілком бачу, як це полегшує управління внесками у ваш проект від інших (наприклад, ваш типовий сценарій Github), схоже, що для "традиційної" команди може виникнути деякі проблеми з централізований підхід, який застосовують такі рішення, як TFS, Perforce тощо. (Під "традиційним" я маю на увазі команду розробників в офісі, що працює над одним проектом, який жодна людина не має у власності ", і потенційно кожен може торкатися одного і того ж коду.)

Пару цих проблем я передбачив самостійно, але, будь ласка, прислухайтесь до інших міркувань.

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

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

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

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

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

Ти сказав:

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

Установка Mercurial за замовчуванням блокує цю поведінку. Це не дозволить натиснути, якщо у віддаленому репо буде створено більше однієї голови, без додаткового підтвердження. Щоденної діяльності ми цього уникаємо. (Git має назва голови, і кожне може бути оновлено, лише якщо повністю об'єднає попередню версію без додаткового підтвердження, тому знову ситуація не може виникнути. Інші DVCS також мають подібний захист.)

Тож наприкінці кожного робочого дня потрібно виділити деякий час для здійснення зобов’язань. Це справді такі дії:

1. Внести місцеві зміни.
2. Потягніть з центрального репо.
3. Об’єднати (і здійснити злиття.)
4. Натисніть на центральний репо.

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

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

Ще одне питання, яке ви згадуєте:

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

Це не створює проблему злиття для нас, але може створити іншу проблему:

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

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

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

Це моя історія, і я її дотримуюся, принаймні, пару хвилин ...

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

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

Описані вами проблеми - це більше про те, як ви вирішили використовувати інструменти.

Ми перейшли з SVN на GIT 6 місяців тому, після використання SVN та GIT локально протягом декількох років. Ніхто не повернеться назад, і хворобливі конфлікти злиття - це минуле. Мантра "Здійсни мале і часто" є ключовим.

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

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

Такий інструмент, як SVN, сильно заохочує тісно інтегрований спосіб роботи.

Тобто, часто здійснюючи спільне використання гілки (стовбура або гілки розробників).

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

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

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

Звичайно, в моєму (обмеженому) досвіді я витрачаю набагато більше часу, працюючи незалежно в моєму колективі (використовуючи Mercurial), ніж у попередніх ролях (Де ми використовували SVN, CVS & P4).

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

Це не обов'язково погано, але я вважаю, що це щось, що потрібно враховувати.

Справа з керуванням версією git / mercurial, полягає в тому, щоби виконувати часто і натискати на централізований сервер, коли код хороший. Одним з великих плюсів є те, що він створює невеликі виправлення, які легко застосувати у випадках конфліктів. Крім того, робочий процес повинен бути чимось у рядках:

1. Багато місцевих зобов’язань
2. Витягнути з сервера
3. Натисніть на сервер

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

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

Звичайно, іноді злиття є кращим рішенням, як приклад, якщо ви працюєте над галуззю функції, яка повинна бути об'єднана в головний.

У своєму робочому процесі ви говорите про те, що люди повинні явно перейти до іншого розробника і сказати йому виправити конфлікт, але це не повинно бути необхідним. Центральний сервер - це «начальник», і над чим ви повинні в основному працювати. Якщо ваші зміни стосуються центрального репо, тоді ви добре. Якщо ні, то ВАШЕ завдання виправити конфлікт, що може зажадати розробника, з яким ви конфліктуєте, щоб допомогти зрозуміти його / її зміни. Це те, що ви бачите при спробі витягнути / відновити з сервера. Тож будьте щасливі вчиняти свої справи та вирішуйте конфлікти, коли вам потрібно вийти з сервера.

Принцип роботи з централізованим сховищем однаковий при роботі з незамикаючою централізованою або розподіленою системою:

• У централізованій системі ви:
  1. Отримайте найновішу версію від mainline ("trunk" в підривному режимі, "master" в git, ...)
  2. Змініть файли
  3. Об’єднайте модифікації з останньою версією від основної лінії за допомогою команди "update"
  4. Зобов’язатись на основній лінії
• У розподіленій системі ви:
  1. Отримайте останню версію від мережі
  2. Змініть файли
  3. Здійснюйте місцеві дії
  4. Об'єднайте модифікації з останньою версією від основної лінії та введіть результат локально
  5. Натисніть на магістраль.

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

Тепер зауважимо, що чотири кроки є однаковими, крім термінології, але розподілені системи додають додатковий крок "3. Здійснити локально". Велика перевага цього кроку полягає в тому, що коли оновлення / виведення створює конфлікти, і ви не знаєте, як їх вирішити чи помилитися, вирішивши їх, ви можете повернутися назад, переглянути те, що ви зробили, і повторити злиття. Subversion не запам’ятає жодне з них, тож якщо ви помилилися, вирішуючи оновлення, вас прикрутили.

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

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