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

Сейчас мы видим гораздо больше ошибок, чем когда мы использовали SVN, некоторые из которых вызваны двухступенчатой ​​моделью Git (локальной и удаленной). Иногда люди совершают, но не в состоянии подтолкнуть, или они тянут и получают конфликты с их ожидающими локальными изменениями. Вчера кто-то засорял недавние изменения - как-то - ошибочным слиянием, которое, я думаю, было слиянием, которое Git делает, когда вы тянете и получаете выдающиеся изменения. (Он не смог сказать мне точно, что он сделал, и, поскольку он использует графический интерфейс, я не могу просто проверить его историю оболочки.)

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

Команда использует Tortoise Git на Windows. Мы используем Tortoise Git, потому что раньше использовали Tortoise SVN. ( Я лично использую командную строку в Cygwin для некоторых операций, но команда ясно дала понять, что им нужен графический интерфейс, и мы собираемся использовать этот.) Ответы должны работать с этим инструментом, а не предлагать замены.

У Tortoise Git «Commit & Push» доступен как одна операция, и я сказал им всегда делать это. Однако это не атомарно - может случиться так, что коммит (который в конце концов является локальным) работает просто отлично, но push не работает (скажем, из-за конфликта или сетевой проблемы). Когда это происходит, они получают неоднозначную ошибку; Я сказал им, чтобы они проверяли журнал коммитов BitBucket, если у них есть какие-либо сомнения относительно недавнего коммита, и, если они этого не видят, нажимать. (И разрешить конфликт, если в этом проблема, или попросить помощи, если они не знают, что делать.)

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

Сервер BitBucket (не Github). У меня есть полный административный контроль над нашим хранилищем, но на сервере нет ни одного более общего. Ничто из этого не изменчиво.

Исходные файлы являются XML. Есть также графические файлы, которые все знают, что вы не можете объединить, но мы также почти никогда не сталкиваемся там. Конфликты слияния происходят от файлов XML, а не от графики.

Какие изменения я могу внести в наше использование Git, чтобы сделать мастер совместного использования более удобным для команды, пока мы не сможем перейти к использованию ветвей функций с проверенными проверенными проверочными запросами?

До сих пор SourceTree был лучшей IDE для изучения концепций, потому что он показывает все соответствующие диалоги и параметры, которые есть у вас на каждом этапе, параметры по умолчанию, как правило, хороши, не возиться с ребазой и т. Д. Просто следуйте обычному потоку:

• Вытащить из мастера, просто чтобы быть в курсе
• Изменить ваши файлы
• Зафиксируйте ваши изменения (только локально)
• Потяните снова от мастера (это приведет к появлению конфликтов)
• Редактируйте все файлы до разрешения конфликтов, что означает, что файл находится в состоянии пропппера, которое вы хотите зафиксировать (без <<<<< HEAD и >>>> мастер-сообщений в необработанном файле)
• Зафиксируйте изменения слияния
• От себя

Если все следуют этому рецепту, они должны быть в порядке.

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

Потратьте много времени на то, чтобы все поняли процесс, в противном случае они могут обойтись некоторое время, а затем почувствовать себя комфортно, фактически крутя основную ветку, например, «использовать мой файл вместо удаленного», чтобы разрешить конфликт, просто пинает все изменения, сделанные другими людьми.

Git - это сложная для изучения система, особенно если вы выросли на Svn, наберитесь терпения и дайте им время, чтобы выучить ее должным образом. С новыми пользователями вы можете иногда тратить день на то, чтобы навести порядок, что нормально. ;)

Есть три основные вещи, которые нужно помнить, когда вы работаете из одной ветки с кем-то еще:

• Никогда не используйте, --forceесли вы действительно не знаете, что делаете.
• Либо commitили stashваша работа в процессе перед каждым pull.
• Обычно это идет легче, если вы pullпрямо перед push.

Кроме того, я укажу, что при распределенном контроле версий не имеет значения, использует ли ваше «официальное» репо ветки или нет. Это не имеет никакого отношения к тому, что отдельные пользователи делают в своих локальных репозиториях. Я использовал git для получения локальных филиалов, когда моя компания использовала совершенно другую центральную VCS. Если они создают локальные ветки для своих функций и делают ошибки слияния со своими локальными master, это намного легче исправить, не вдаваясь в reflog или какую-то другую магию.

Разве можно потратить день на изучение гита?

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

Лучший способ представить это - заставить каждого работать над собственной веткой, когда они вносят изменения (как можно короче), и выполнять ребазинг, а затем объединяться с мастером, когда они это сделают. Это не слишком далеко от нынешнего способа работы и представляет простой рабочий процесс, к которому они могут привыкнуть, пока не почувствуют себя достаточно уверенно для выполнения более сложных операций.

Я не использую окна, но если Tortoise в основном скрывает git от них и делает вид, что это SVN, то, возможно, Tortoise - не тот инструмент.

Иногда то, что вы делаете, должно измениться.

Самая большая проблема в том , что все это работает на хозяина. Это не типично для разработки кода и может быть неправильной моделью в вашем случае. Если вы можете изменить это, попросив / потребовав внести изменения в отдельных ветвях, вы будете в гораздо лучшей форме. С помощью веток вы можете получить следующее:

• Обеспечить, чтобы никакие толчки не masterбыли разрешены напрямую .
• Примените через Bitbucket, что запросы на извлечение создаются и имеют по крайней мере одно утверждение перед слиянием . Это гарантирует, что кто-то смотрит на изменения, а также делает слияние менее болезненным, поскольку пользовательский интерфейс будет показывать конфликты с удаленной версией кода, а не с тем, что есть у пользователя на рабочем столе. Это предотвращает сценарий фиксации-успешной-но-принудительной неудачи.
• Выполните «сборки» против вашего репо до слияния. Я понимаю, что это репозиторий документов, но, возможно, есть проверка орфографии, юридическая проверка или даже автоматический перевод (экспорт вещей STRING_DEF в CSV-файл), который можно построить из этой сборки. А может и нет, зависит от вашей работы.
• Позвольте людям работать над несколькими разными вещами одновременно проще. Да, это можно сделать и с тайниками, но это немного более грязно, и что-то подсказывает мне, что ты тоже их не используешь.

Если вы не можете использовать ветвление, вы можете написать merge-and-pushскрипт, который бы автоматизировал некоторые болевые точки. Может быть, он проверит, что пользователь не отстает от мастера, сделает выборку и извлечение, а затем попытается объединить ( возможно, с--no-commit --no-ff ) и так далее.

Подчеркните, что вы можете повторить слияния

Это может быть очевидно для вас, но бывшие пользователи SVN могут не знать, что они могут попытаться выполнить объединение несколько раз. Это может сократить количество флагов помощи, которые вы получаете.

В SVN при отработке у trunkвас будут изменения, не совершенные сидя. Тогда вы бы сделали svn update. В этот момент ваши изменения будут смешиваться с изменениями других людей навсегда. Не было никакого способа отменить это (afaik), поэтому у вас не было выбора, кроме как просто проверить все вручную и надеяться, что репо было в хорошем состоянии. Когда на самом деле вам будет гораздо удобнее просто переделать слияние.

У людей был бы такой же менталитет, даже когда мы перешли на Git. Приводит к множеству непреднамеренных ошибок.

К счастью, с git есть обратный путь, особенно потому, что вы можете делать локальные коммиты. (Позже я опишу, как это выражается в командной строке)

Хотя, как это сделать, будет зависеть от инструментов. Я считаю, что повторное нажатие не во многих графических интерфейсах отображается как отдельная кнопка, но, вероятно, возможно. Мне нравится, что вы используете Cygwin. Мои коллеги используют sourcetree. Поскольку вы используете BitBucket, имеет смысл использовать его в качестве графического интерфейса, поскольку он управляется одной и той же компанией: Atlassian. Я подозреваю, что есть более тесная интеграция.

Относительно тянет

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

В результате все стандартные команды слияния работают с pull. Если у этого слияния есть конфликты, вы можете прервать его git merge --abort. Который должен вернуть вас до вашего слияния. Затем вы можете попробовать еще раз с git pullили git merge origin/<branchname>.

Если вы можете каким-то образом научиться делать вышеперечисленное, используя графический инструмент вашего коллеги, я думаю, что это решит большинство ваших проблем. Извините, я не могу быть более конкретным.

* Я понимаю, что происхождение здесь не всегда так.

Используйте git reflogдля диагностики проблем

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

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

Поскольку ваша ситуация временная , вы можете просто вернуться в SVN, пока не начнете процесс развертывания. Я не решался бы сделать это, так как многие места говорили бы: «Мы попробовали git один раз, но это просто не сработало ...» и никогда бы не подняли его обратно.

Некоторые другие общие проблемы переходного периода

• Люди часто удаляли и откладывали репо, будучи убежденными, что репо находится в непригодном для использования состоянии. Обычно это было вызвано потерей отслеживания локальной и удаленной разницы. И инструменты GUI, и CLI не показывают это хорошо. В CLI я нахожу git log --decorateсамый простой способ рассмотреть различия. Но если на хозяине (например) дела становятся слишком волосатыми, вы можетеgit reset --hard origin/master

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

В этом каждый разработчик или суб-команда имеет свою собственную вилку из хранилища, они проверяют из BitBucket обеспечивает механизм для этого , установив «вверх» происхождения в дополнение к удаленным по умолчанию - они должны помнить , чтобы «принести вверх по течению "и" объединить удаленный / upstream / master "на регулярной основе.

Это, возможно, решит ваши проблемы с механизмом сборки, так как инструменты сборки, возможно, будут направлены к мастеру в другом проекте, то есть в форке.

После этого вы могли бы отстранить большинство людей от возможности непосредственно перейти к основному проекту и создать небольшую группу людей с проверкой и утверждением ролей. См. Https://www.atlassian.com/git/tutorials/making-a-pull-request.

Место, где можно прочитать о том, чтобы убедиться, что почти все желаемые проверки выполняются перед нажатием, находится в разделе git book о хуках - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - вы можете использовать ловушки pre-commit и pre-push, чтобы выполнять такие вещи, как запуск некоторых тестов на предложенном коммите, чтобы убедиться, что работа корректна и т. д. - единственная проблема с ловушками на стороне клиента состоит в том, что разработчики могут отключить их или не включить их.

В TortoiseGit доступны как извлечение / слияние, так и перехватчики.

Это будет звучать нелогично, но выслушайте меня:

Поощряйте их, чтобы начать экспериментировать с git

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

Боязнь пробовать что-то - одно из самых больших препятствий для изучения мерзавца. Это дает вам так много контроля над всем, что это немного утомительно. Реальность такова, что вы можете придерживаться нескольких очень безопасных операций для большей части вашего ежедневного использования, но выяснение, какие команды это те, требует некоторого изучения.

Предоставляя им чувство безопасности , они будут гораздо охотнее пытаться понять, как все делать самостоятельно. И у них будет гораздо больше возможностей найти личный рабочий процесс на своей локальной машине, который работает на них. И если не все делают то же самое на местном уровне , это нормально, если они придерживаются стандартов, которые они продвигают . Если для того, чтобы они чувствовали себя таким образом, нужно сжать весь репо, это нормально; они могут найти лучшие способы делать что-то по ходу дела и когда они что-то пробуют. Что-нибудь, чтобы заставить себя начать пробовать вещи и видеть, что они делают.

Это не значит, что обучение бесполезно. Напротив, обучение может помочь познакомить вас с особенностями и закономерностями. Но это не замена того, чтобы сидеть и делать что- то в своей повседневной работе. Ни git, ни SVN не являются вещами, которые вы можете просто пойти в класс, и тогда вы все знаете. Вы должны использовать их для решения своих проблем, чтобы ознакомиться с ними и какие функции хорошо подходят для каких проблем.

Хватит отговаривать их изучать все тонкости мерзости

Я упоминал, что ничего не толкаю, что на самом деле идет вразрез с одной из вещей, которой вы их учили: всегда «совершать и толкать». Я считаю, что вы должны перестать говорить им делать это и сказать им, чтобы начать делать обратное. Git имеет в основном 5 «мест», где ваши изменения могут быть:

• На диске незафиксировано
• Поставлено, но не совершено
• В локальном коммите
• В местном тайнике
• Удаленные репозитории (Только коммиты и теги когда-либо помещаются в разные репозитории)

Вместо того, чтобы поощрять их тянуть и толкать все за один шаг, поощряйте их использовать эти 5 разных мест. Поощряйте их:

• Получить изменения, прежде чем они что-то совершают.

• Примите решение, как обрабатывать извлеченные изменения. Варианты:

  • Зафиксируйте их локальные изменения, затем перебазируйте их поверх извлеченных изменений.
  • Зафиксируйте их локальные изменения, а затем выполните слияние с извлеченными изменениями.

  • Спрятать их изменения, объединить, а затем распаковать и разрешить любые конфликты.

    Есть и другие вещи, но я не буду вдаваться в подробности. Обратите внимание, что тяга - это буквально просто выборка и слияние. Это не похоже на них; это является их. (Передача --rebaseизменений вытащить из fetch + merge для fetch + rebase.)

• Подготовьте их изменения, а затем просмотрите их.
• Зафиксируйте их поэтапные изменения, а затем просмотрите коммит.
• Нажмите отдельно.

Это побудит их проверить свою работу, прежде чем она станет общедоступной, что означает, что они поймают свои ошибки раньше. Они увидят коммит и подумают: «Подождите, это не то, что я хотел», и в отличие от SVN, они могут вернуться и попробовать еще раз, прежде чем нажать.

Как только они привыкнут к пониманию того, где находятся их изменения, они могут начать решать, когда пропустить шаги и объединить определенные операции (когда тянуть, потому что ты уже знаешь, что хочешь получить + объединить или когда щелкнуть по этой опции Commit & Push) ,

На самом деле это одно из огромных преимуществ git по сравнению с SVN, и git разработан с учетом этой модели использования. SVN, напротив, предполагает центральное хранилище, поэтому неудивительно, если инструменты для git не так оптимизированы для того же рабочего процесса. В SVN, если ваш коммит неверен, единственным реальным выходом является новый коммит, чтобы исправить ошибку.

Это, естественно, приведет к следующей стратегии:

Поощряйте их использовать местные филиалы

Локальные филиалы облегчают работу с общими файлами. Я могу сделать все изменения, которые я хочу, в моей собственной ветке, и это никогда никого не затронет, так как я их не настаиваю. Затем, когда придет время, я могу использовать все те же стратегии слияния и перебазирования, только проще:

• Я могу перебазировать свою локальную ветку, что делает слияние ее с основным тривиальным.
• Я мог бы использовать простое слияние (создать новый коммит) в master, чтобы внести в него изменения моей локальной ветки.
• Я могу объединить всю локальную ветку в один коммит на мастере, если я думаю, что моя ветвь слишком беспорядочная для спасения.

Использование локальных ветвей также является хорошим началом для определения систематической стратегии ветвления. Это помогает вашим пользователям лучше понять их собственные потребности в ветвлении, поэтому вы можете выбрать стратегию на основе потребностей и текущего уровня понимания / навыков команды, а не просто отказаться от Gitflow, потому что все об этом слышали.

Резюме

Короче говоря, git не является SVN и не может рассматриваться как это. Тебе следует:

• Устраните страх, поощряя безопасные эксперименты.
• Помогите им понять, как git отличается, чтобы они могли видеть, как это меняет их обычный рабочий процесс.
• Помогите им понять доступные функции, чтобы помочь им легче решать свои проблемы.

Все это поможет вам постепенно перейти к лучшему использованию git, пока вы не достигнете того уровня, когда сможете приступить к внедрению набора стандартов.

Особенности

В ближайшей перспективе следующие идеи могут помочь.

Rebase

Вы упомянули ребаз и что вы не совсем понимаете это в своем вопросе. Итак, вот мой совет: попробуйте то, что я только что описал. Внесите некоторые изменения локально, в то время как кто-то еще подтолкнет некоторые изменения. Передайте ваши изменения локально . Заархивируйте свой каталог репозитория в качестве резервной копии. Получить изменения другого человека. Теперь попробуйте запустить команду rebase и посмотрите, что происходит с вашими коммитами! Вы можете читать бесконечные посты в блоге или проходить тренинги о 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) Каждый использует свою собственную ветку, которая изначально является копией основной ветки.

Давайте назовем основную ветку «master», а мою собственную ветку «my_master».

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

В данный момент на моей ветке, только что закончил кодирование

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

Невозможно иметь конфликты, поскольку они разрешаются в вашей собственной ветке с предыдущим слиянием.

Пуш мастер

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, например, чтобы сделать эту работу без какой-либо боли.