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

Зараз ми спостерігаємо набагато більше гикавок, ніж коли ми використовували SVN, деякі з яких спричинені двоступеневою моделлю Git (локальною та віддаленою). Іноді люди беруть на себе зобов’язання, але не вдається просунути їх, або вони тягнуться і вступають у конфлікти зі своїми очікуваними локальними змінами. Вчора хтось клопотав про останні зміни - якимось чином - злиття пішло не так, що, на мою думку, було злиттям, яке робить Git, коли ти тягнеш і маєш видатні зміни. (Він не зміг точно сказати мені, що він зробив, і тому, що він використовує GUI, я не можу просто перевірити його історію оболонки.)

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

Команда використовує Tortoise Git у Windows. Ми використовуємо Tortoise Git, тому що раніше використовували Tortoise SVN. ( Я особисто використовую командний рядок під Cygwin для деяких операцій, але команда дала зрозуміти, що їм потрібен графічний інтерфейс, і ми йдемо з цим.) Відповіді повинні працювати з цим інструментом, а не пропонувати заміни.

Черепаха Гіт має "Здійснити та натиснути" в якості однієї операції, і я сказав їм завжди робити це. Однак це не атомно - може статися, що фіксація (яка врешті-решт є локальною) працює чудово, але натиск не працює (скажімо, через конфлікт чи проблему з мережею). Коли це відбувається, вони отримують неоднозначну помилку; Я сказав їм , щоб перевірити BitBucket зробити журнал , якщо у них є якісь - або сумніви відносно недавно зробити і, якщо вони не бачать його, штовхати. (І щоб вирішити конфлікт, якщо це проблема, або попросити допомоги, якщо вони не знають, що робити.)

У команди вже є добра звичка «тягнути рано і часто». Однак виявляється, що тяга може викликати конфлікти, що, на мою думку, є новим? Якщо не новий, то набагато частіше, ніж у SVN. Я чув, що я можу змінити те, як Git робить тягнення (перестановка замість злиття), але я не дуже добре розумію компроміси там (або як це зробити в нашому середовищі).

Сервер - BitBucket (не Github). Я маю повний адміністративний контроль над нашим сховищем, але загалом немає жодного сервера. Ніщо з цього не змінюється.

Вихідними файлами є XML. Є також графічні файли, які всі знають, що ви не можете злитися, але у нас також майже ніколи не виникає зіткнень. Конфлікти злиття виникають із XML-файлів, а не графіки.

Які зміни я можу внести до використання Git, щоб змусити майстра спільного використання пройти більш плавно для команди, поки ми не зможемо перейти до використання функціональних гілок з переглянутими, перевіреними тестовими запитами на витяг?

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

• Потягніть від майстра, просто щоб бути впевненим, що ви в курсі
• Змініть свої файли
• Внесіть свої зміни (це лише локально)
• Потягніть знову з майстра (це спричинить конфлікти)
• Редагуйте всі файли, поки конфлікти не будуть вирішені, тобто файл знаходиться у стані проппера, який ви хочете зробити (у вихідному файлі немає <<<<< HEAD та >>>> головних повідомлень)
• Зробіть зміни злиття
• Штовхати

Якщо всі дотримуються цього рецепту, вони повинні бути добре.

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

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

Git - це складна для засвоєння система, особливо якщо ви виросли зі Svn, будьте терплячі та дайте їм час, щоб вони це навчились належним чином, з новими користувачами ви можете іноді провести день, прибираючи якийсь безлад, це нормально. ;)

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

• Ніколи не використовуйте, --forceякщо ви дійсно не знаєте, що робите.
• Або кожен, commitабо stashваша робота триває перед кожним pull.
• Зазвичай це простіше, якщо ви pullпрямо перед a push.

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

Чи можна взяти день, щоб кожен вивчив git?

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

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

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

Іноді те, що ти робиш, має змінитися.

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

• Зверніть увагу, що ніяких натискань безпосередньо masterдозволено.
• Примушуйте за допомогою Bitbucket створювати запити на витягування та мати принаймні одне схвалення до об'єднання . Це гарантує, що хтось дивиться на зміни, а також робить само злиття менш болісним, оскільки інтерфейс користувача демонструватиме конфлікти проти віддаленої версії коду, а не того, що має користувач на робочому столі. Це запобігає розвитку сценарію, який вдався, але не вдався.
• Виконайте "складання" проти вашого репо перед тим, як об’єднати. Я усвідомлюю, що це doc repo, але, можливо, є перевірка орфографії, легального скреблінгу або навіть автоматизованого перекладу (експорт STRING_DEF речей у файл CSV), який може бути складений з цієї збірки. А може й ні, залежить від вашої роботи.
• Дозвольте людям працювати над кількома різними речами одночасно легше. Так, це можна зробити і за допомогою сташів, але це трохи мідніше, і щось говорить про те, що ви також не використовуєте їх.

Якщо ви не можете використовувати розгалуження, ви можете розглянути можливість написання merge-and-pushсценарію, який може автоматизувати деякі больові точки. Можливо, це перевірить, чи користувач не відстає від майстра, зробить витяг та потягне, а потім спробує об'єднати ( можливо, з--no-commit --no-ff ) тощо.

Підкресліть, що ви можете повторно об'єднати

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

У SVN, коли ви працюєте, у trunkвас не буде змін, коли ви сидите. Тоді ви зробите svn update. Після цього ваші зміни назавжди змішаться з іншими змінами. Зняти це не вдалося (афаїк), тому у вас не було іншого вибору, як просто вручну перевірити все і сподіватися, що репо було в хорошому стані. Коли насправді вам буде набагато комфортніше, просто переробляючи злиття.

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

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

Хоча як це робиться, буде залежати від інструментів. Я вважаю, що повторне витягнення не є чимось викритим у багатьох графічних інтерфейсах як одна кнопка, але, ймовірно, це можливо. Мені подобається, що ти використовуєш cygwin. Мої колеги використовують sourcetree. Оскільки ви використовуєте BitBucket, було б доцільно використовувати його як свій графічний інтерфейс, оскільки ним керує та сама компанія: Atlassian. Я підозрюю, що є якась більш тісна інтеграція.

Щодо тягне

Я думаю, ти маєш рацію, що злиття pull- це те, що псує людей. A pullнасправді git fetchотримує зміни з сервера, а потім git merge origin/<branchname>*, що об'єднує віддалені зміни у вашу локальну гілку. ( https://git-scm.com/docs/git-pull )

Підсумок - це всі стандартні команди злиття, які працюють з потягуванням. Якщо злиття має конфлікти, ви можете перервати git merge --abort. До чого слід повернути вас до злиття. Потім ви можете спробувати ще раз з git pullабо git merge origin/<branchname>.

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

* Я розумію, що походження не завжди так.

Використовуйте git reflogдля діагностики проблем

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

Альтернатива

Оскільки ваша ситуація тимчасова , ви можете просто повернутися до SVN, поки у вас не буде процесу для розгортання. Я б вагався зробити це, оскільки багато місць продовжували б говорити: "Ми спробували git один раз, але це просто не вийшло ...", і ніколи насправді не підбирати його.

Деякі інші загальні перехідні проблеми

• Люди часто видаляли і повторно відновлювали своє репо, переконавшись, що їх репо знаходиться у непридатному стані. Зазвичай це було викликано втратою сліду локальної та віддаленої різниці. Як інструменти графічного інтерфейсу, так і CLI не вдається це добре показати. У CLI я знаходжу git log --decorateнайпростіший спосіб переглянути відмінності. Але якщо у господаря (наприклад) речі занадто волохаті, можнаgit reset --hard origin/master

Один з можливих механізмів, який прийняли багато команд з відкритим кодом, - це використовувати модель розгортання - https://www.atlassian.com/git/tutorials/comparing-workflows (обов'язково чітко проговоріть, обговорюючи робочий процес forking git ) .

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

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

Потім ви зможете усунути у більшості людей можливість прямо спрямовуватися на головний проект і зробити так, щоб менша група людей переглядала та затверджувала ролі. Дивіться https://www.atlassian.com/git/tutorials/making-a-pull-request

Місце для читання щодо забезпечення майже будь-яких бажаних перевірок перед натисканням - у розділі книги git на гачках - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - ви можете використовувати гачки попереднього введення та попереднього натискання, щоб виконувати такі дії, як виконання деяких тестів на запропонованій комісії, щоб переконатися, що робота є дійсною тощо. - Єдина проблема з гачками на стороні клієнта полягає в тому, що розробники можуть їх відключити або не ввімкнути їх.

У TortoiseGit доступні обидві витяжки / злиття та зачеплення.

Це буде звучати контрінтуїтивно, але почуйте мене:

Заохочуйте їх почати експериментувати з git

Однією з цікавих речей про git є те, що напрочуд легко зробити будь-яку локальну операцію повністю безпечною. Коли я вперше почав використовувати git, однією з речей, за якими я виявив себе, було застебнення всього каталогу як резервного копіювання на випадок, якщо я щось накрутив. Пізніше я виявив, що це величезна хитрість і майже ніколи насправді не потрібно захищати свою роботу, але вона має честь бути дуже безпечною і дуже простою, навіть якщо ви не знаєте, що в чортові ви робите і як вийде команда, яку потрібно спробувати. Єдине, чого вам слід уникати, коли ви робите це push. Якщо ви нічого не натискаєте, це 100% безпечний спосіб спробувати все, що завгодно.

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

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

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

Перестаньте відмовляти їм у навчанні гри та гри

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

• На диску, не передається
• Постановочна, але не вчинена
• У місцевому комітеті
• У місцевому сховищі
• Віддалені сховища (лише коміти та теги колись пересуваються та перетягуються між різними сховищами)

Замість того, щоб заохочувати їх тягнути і штовхати все за один крок, заохочуйте їх використовувати ці 5 різних місць. Заохочуйте їх до:

• Отримати зміни, перш ніж щось зробити.

• Прийміть рішення, як впоратися з отриманими змінами. Варіанти:

  • Введіть їхні локальні зміни, а потім перезавантажте їх на основі отриманих змін.
  • Введіть їхні локальні зміни, а потім зробіть злиття із отриманими змінами.

  • Приховайте їх зміни, з’єднайте, а потім видаліть і вирішіть будь-які конфлікти.

    Є інші речі, але я сюди не ввійду. Зауважте, що тягнення - це буквально лише збіг та злиття. Це не так, як вони; це є їх. (Передача --rebaseзмін тягнеться з "виймання" + "злиття" для "отримання" ("база даних").

• Поетапно зміни їх, а потім переглянь їх.
• Внесіть їх поетапні зміни, а потім перегляньте.
• Натисніть окремо.

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

Як тільки вони звикнуть до ідеї зрозуміти, де їх зміни, тоді вони можуть почати вирішувати, коли пропустити кроки та комбінувати певні операції (коли витягнути, оскільки ви вже знаєте, що хочете отримати + злиття або коли натиснути цю опцію «Зв’язати та натиснути») .

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

Це фактично природно призведе до наступної стратегії:

Заохочуйте їх використовувати місцеві відділення

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

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

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

Підсумок

Коротше кажучи, git не є SVN і не може так поводитися з ним. Тобі потрібно:

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

Все це допоможе вам поступово застосовувати краще використання git, поки ви не досягнете того моменту, коли зможете розпочати впровадження набору стандартів.

Особливості

У найближчий термін можуть допомогти наступні ідеї.

База даних

Ви згадали про базу даних і не дуже розумієте її у своєму питанні. Тож ось моя порада: спробуйте те, що я щойно описав. Внесіть деякі зміни локально, тоді як хтось інший натискає на деякі зміни. Внесіть зміни на місцевому рівні . Створіть каталог репозиторіїв як резервне копіювання. Отримати зміни іншої людини. Тепер спробуйте запустити команду rebase і подивіться, що відбувається з вашими зобов’язаннями! Ви можете читати нескінченні дописи в блозі або проходити навчання щодо перезавантаження і того, як слід чи не слід користуватися ним, але жодне з них не є заміною для того, щоб побачити його в прямому ефірі. Тож спробуйте .

merge.ff=only

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

git config --global merge.ff only

"ff" означає "швидкий вперед". Швидке злиття вперед - це коли git не потрібно поєднувати зміни з різних комітетів. Він просто переміщує вказівник гілки вгору до нового коміту по прямій графіці.

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

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

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

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

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

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

Ну, нещодавно я адаптував такий робочий процес, щоб ніколи не запускати головну гілку:

1) Кожен користується власною гілкою, яка по суті є копією з головного відділення.

Назвемо головну гілку "майстер", а мою власну гілку - "мій_майстер".

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

Currenly на моїй гілці, щойно закінчила кодування

git add . && git commit -m "Message" && git push

Поверніться до головного відділення

git checkout master

Потягніть, якщо це не в курсі

git pull

Поверніться до мого власного відділення

git checkout my_master

Приєднайте останнього майстра до моєї власної філії

git merge master

Виправлення конфліктів та злиття

Перевірте все ще раз

Коли все з’єднано і виправлено на моїй власній гілці, натисніть на неї

git push

Поверніться до головного відділення

git checkout master

Об’єднатися з моєю гілкою

git merge my_master

Неможливо мати конфлікти, оскільки вони вирішуються на вашій власній гілці з попереднім злиттям

Push master

git push

Якщо всі слідкують за цим, головна гілка буде чистою.

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

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

Загальні процедури, щоб зробити це максимально безболісним:

1. робити git stash && git pull --rebase && git stash popщоранку
2. робити рано і часто (не потрібно натискати негайно; ми можемо принаймні почати користуватися цією перевагою git рано)

3. для натискання робимо наступний цикл:

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

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

Ви повинні використовувати майстер для готових продуктів, які надсилаються замовнику. Ви повинні використовувати розробку для постійного розвитку, і ви не повинні дозволяти нікому підштовхувати до розвитку. Стандартом є те, що всі відділяються від dev, вносять свої зміни, висувають їх із локальної в свою гілку на сервері та видають запит на push. Потім хтось переглядає зміну і об'єднує її в розвиток.

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

Наприклад, ви можете використовувати sourcetree, щоб зробити цю роботу без будь-якого болю.