Как я могу минимизировать боль при мерзости, когда все работают над мастером?

123

Наша команда по документации из десяти человек недавно переехала из 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, чтобы сделать мастер совместного использования более удобным для команды, пока мы не сможем перейти к использованию ветвей функций с проверенными проверенными проверочными запросами?

Моника Челлио
источник
52
Не используйте черепаху, используйте Git Extensions. Черепаха пытается скрыть, что Git не SVN и уничтожает большую часть величия Git. Я дважды прошел SVN-> Git transistion, и Git Extension был отличным инструментом, чтобы заставить людей думать о git-стиле.
Уилберт
91
Git это не SVN. Если вы попытаетесь скопировать SVN с помощью Git, вы просто получите все болевые точки SVN со всеми болевыми точками Git вместе, ни с одним из преимуществ, это просто не сработает. Самая большая проблема у вас - это социальная проблема, у вас есть члены команды, которые отказываются изучать новые концепции. Вы не можете решить эту проблему с помощью технического решения, вам нужно начать с того, чтобы получать от своих членов команды бай-ины для изучения концепций Git, а не пытаться убедить их в том, что это похоже на SVN.
Ли Райан
10
Я знаю, что вы сказали не рекомендовать другие приложения, но @Wilbert это правильно. TortoiseGit пытается скрыть вещи, что на самом деле делает их более болезненными в моем опыте. Если пользовательский интерфейс желателен, я обнаружил, что самый простой переход (читай: я обучаю нетрадиционные команды разработчиков программного обеспечения инструментальным средствам и DevOps) был сделан через SourceTree Atlassian (с должным обучением, конечно). Я также использовал GitFlow, чтобы помочь им понять модель Git (хотя это подходит не всем командам).
JasCav
28
Я немного удивлен, что все работают над мастером, который является основным принципом непрерывной интеграции . Пока у вас есть надежный набор тестов, и все знают, когда сборка не работает, работа с мастером может быть выгодна для совместной работы команды. Разветвление функций (на которое в значительной степени опираются все другие рабочие процессы) может быть в равной степени разрушительным и без защиты. У вас, вероятно, здесь есть некоторые более глубокие проблемы с корнем.
DanK
14
@DanK, я также думаю, что операция неправильно определила корень проблемы. Если у вас есть люди, которые блокируют изменения на главном сервере, и вы переключаетесь на ветку, у вас будут люди, которые блокируют изменения на ветке. Если вы перейдете к отдельным веткам, у вас будут люди, у которых проблемы со слиянием в своих ветках (или те, кто развивается в своей ветке без слияния в течение нескольких месяцев подряд).
user3067860

Ответы:

11

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

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

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

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

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

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

Майк М.
источник
9
Нитпик: SourceTree не является интегрированной средой разработки ...
Матье Гиндон,
У меня есть кто-то (кроме меня), который сейчас тестирует этот рабочий процесс (я имею в виду Tortoise Git), чтобы избавиться от любых неожиданностей / проблем. Предполагая, что нет, я планирую передать это команде через пару дней.
Моника
Я знаю, что этот голос с высоким рейтингом охватывает большую часть той же территории, что и этот, но только когда я увидел шаг за шагом изложенный в этом ответе рецепт, я действительно понял, как его применять, поэтому я Я принимаю это (для рецепта, а не IDE :-)). Мы следим за этим процессом уже несколько дней без каких-либо проблем. Мы также уделим больше внимания изучению и пониманию «мерзавца».
Моника
99

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

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

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

Карл Билефельдт
источник
51
Всегда , pullпрежде чем pushэто большой совет, но я бы один шаг дальше и предположить , что вы считаете , можете ли Вы , pull --rebaseкогда вы делаете.
Анаксимандр
20
@anaximander, я бы порекомендовал, чтобы либо все использовали --rebase, либо никто ...
keuleJ
12
@TemporalWolf Вот что они рассказали мне и о торте тоже ...
BlackVegetarian
15
@anaximander "тогда вы не разрешили конфликт, и вы делаете это неправильно. В этом случае им нельзя доверять с помощью rebase". Таким образом, вы говорите, что никогда ни разу не перепутали конфликт слиянием? Должно быть приятно работать с достаточно простыми основами кода, чтобы вы могли сделать это обобщение. Вот что делает Линус на ребазе, и я лично нахожу его более приятным, чем любой из этих черно-белых подходов.
Voo
10
«Никогда не используйте, --forceесли вы действительно не знаете, что делаете». Я бы пошел дальше. Запретить переписывание истории в «основном» хранилище от всех, кроме самых доверенных лиц. Сможете ли вы сделать это хотя бы частично, зависит от вашего хостинга, но у BitBucket есть такая возможность.
jpmc26
68

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

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

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

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

MarkJL
источник
37
«если Черепаха в основном скрывает от них мерзавца и притворяется, что это SVN, то, возможно, Черепаха - неправильный инструмент». это. Я знаю, что OP сказал не заменять инструмент, но если он каким-то образом затеняет работу git, это наносит ущерб личному росту ваших разработчиков и вашей операционной эффективности. Ваша команда продолжит злоупотреблять вашей VCS, если они этого не понимают.
2rs2ts
3
Еще один полезный ресурс для изучения git - Learn Git Branching . Он показывает визуальное дерево и, кроме того, имеет «песочницу», так что вы можете смоделировать кучу команд и посмотреть, что за дерево получится.
TemporalWolf
4
Все в команде разработчиков заняли намного больше времени, чем день, чтобы выучить git (и они не тусклые или бездельники), поэтому я предположил, что это будет верно и для команды разработчиков. Я посмотрю на сайты, упомянутые здесь в комментариях (может быть, они должны быть в том или ином ответе?).
Моника
3
Вы не будете изучать git до тех пор, пока не сделаете все ошибки и не почувствуете боль от конфликтующих слияний и перебазировок, им просто нужно изучить короткий вышеописанный процесс создания ветви, перебазируя эту ветку, чтобы включить любые изменения из master и объединяя их филиал обратно в мастера. Любое другое обучение, которое они могут сделать, поскольку они пытаются решить любую боль, с которой они сталкиваются в этом потоке (будут некоторые). По крайней мере, команда разработчиков документации не заботится о взломе кода.
MarkJL
1
@ 2rs2ts Черепаха Git является исключительным Git Gui. Я установил его на все свои окна, и я очень хорошо знаком с командной строкой git. Его mergetool - один из лучших, которые я когда-либо использовал. Я представил многим начинающим пользователям git, используя Tortoise Git. Самая большая проблема заключается в том, что он предоставляет некоторые дополнительные параметры git с помощью простого флажка. Поэтому такую ​​опцию, как --force push, можно сделать, просто установив флажок в push-интерфейсе. Это вероятно то, что было сделано, что потеряло работу. Я не использую черепаху много, но есть несколько вещей, которые действительно упрощают.
gnash117
26

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

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

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

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

Dan1701
источник
3
Мы собираемся перейти к ветвлению по всем причинам, которые вы упомянули (но особенно это касается контролируемых PR и возможности поручить разрешение конфликтов в ветви до слияния). Не могли бы вы рассказать подробнее о том, как атаковать сценарий слияния и удаления?
Моника
6
Я не согласен с этим советом. Долгосрочные ветви функций могут быть гораздо более разрушительными, чем работа с мастером (что, если у вас нет хорошего рабочего процесса, это то, что должно произойти). У Мартина Фаулера есть отличная статья на эту тему. В конце дня у команды OP возникла проблема с совместным рабочим процессом, а не проблема Git. Я бы сказал, что большее количество ветвей просто усугубит эту проблему.
DanK
6
Долгосрочные ветки функций - это не то, что я защищал (и не упомянул). Я согласен, что они вредны для "регулярного" развития, и здесь было бы не лучше. Регулярные ветки "ravioli" с небольшими наборами изменений, которые можно проверить / протестировать до слияния, очень полезны и не менее полезны здесь только потому, что это репозиторий по всем причинам, изложенным в ответе.
Dan1701
3
Конечно, я понимаю, что вы говорите, и я не согласен в теории, но с проблемами сотрудничества, которые в настоящее время описываются здесь, даже с самыми лучшими намерениями, я думаю, что ветви команды OP все непреднамеренно превратятся в долгосрочные ветви. В конце концов, работа над основной веткой и функциональной ветвью здесь не является основной проблемой. Проблема заключается в общем непонимании входов / выходов распределенной VCS и отсутствии сотрудничества / сплоченности среди разработчиков. Разветвление функций само по себе не исправит это, но IMO усугубит это.
DanK
2
Мы приближаемся к необходимости перенести это в чат, но, если вы всегда находитесь в ветке функций, значит, вы не заканчиваете свою работу. Они должны быть объединены с отправленной веткой (или опубликованы, в этом случае). Это позволяет внедрить автоматизированные проверки и меры защиты от проблем, с которыми сталкивается их команда. Функциональная ветвь полностью отличается от работы над мастером тем, что большинство инструментов (по крайней мере, Bitbucket) настроены так, чтобы разрешать запросы извлечения с необходимыми одобрениями и сборками перед слиянием как часть модели ветвления, что не происходит при работе только над master,
Dan1701
12

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

Это может быть очевидно для вас, но бывшие пользователи 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
jmathew
источник
2
И последнее замечание: для действительно быстрого структурного обзора я считаю git log --oneline --decorate --graphидеальным. Настолько, что я определил псевдоним оболочки для этой точной комбинации.
Мастер
1
+1 за ваш ответ, я просто считаю предложенную альтернативу плохой, по причине, которую вы упомянули. У вас будет боль, даже если вы вернетесь в SVN, а затем в будущем зайдете в git. Люди в команде изучат новый, другой, болезненный инструмент, только если у них нет другого выбора. Только после использования и совершения глупых ошибок они начнут ценить то, что может делать git.
CodeMonkey
8

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

Стив Барнс
источник
Неплохая идея, правда. Также похоже, что эта команда выиграет от Merge Master, пока не станет более комфортной. +1
Грег Бургхардт
2
BitBucket имеет функцию синхронизации вилки, которая автоматически перематывает форки, когда это возможно. Сегодня очень удобно раскошелиться и вытащить из источника на следующей неделе, не беспокоясь о добыче.
Пьедар
3

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

Поощряйте их, чтобы начать экспериментировать с 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чтобы обойти конфигурацию), или я могу просто отложить объединение моих изменений сейчас и обработать его позже. Я думаю, что этот небольшой скачок скорости поможет вашей команде избежать принятия неправильных решений о слияниях. Вы можете позволить своей команде отключить его, как только они справятся со слияниями.

jpmc26
источник
2

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

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

Мы приняли (довольно радикальное) решение заставить разработчиков использовать командную строку (git bash или posh-git ) в течение недели, и это дало чудеса для понимания того, как на самом деле работает git и чем он отличается от SVN. Это может звучать радикально, но я бы посоветовал вам попробовать это просто потому, что это создает понимание модели git - и, как только они это уладят, ваши коллеги могут начать использовать любые фасады GUI поверх git, которые им нравятся.

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

Ян Кемп
источник
1

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

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

Если все последуют этому, основная ветвь будет чистой.

TanguyB
источник
0

Таким образом, у нас есть команда, которая перешла с 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.

Джошуа
источник
Если вы сделаете это, вы можете остаться в SVN. Так же было и с конными повозками во времена автомобилей. Конечно, вы можете вести машину с той же скоростью, что и с лошадиной. Но все, чего ты добиваешься при этом, - это помешать себе и заставить людей, способных водить машину, злиться на тебя. Научитесь водить машину. В настоящее время.
Мастер
@cmaster: Для нас главным преимуществом git было то, что потеря сервера не теряет всю историю контроля версий. (Это случилось с нами - у нас были резервные копии, но накопитель на магнитной ленте начал есть ленты, когда мы пытались восстановить.)
Иисус Навин
@cmaster: С тех пор мы начали внедрять некоторые другие полезные функции git, но ветвление изменений, вероятно, не будет использовано.
Иисус Навин
@cmaster Разница между медленным вождением автомобиля и ездой на лошади заключается в том, что вождение автомобиля подготавливает вас к вождению быстрее. Езда на лошади не Не всем, кто запрыгивает в машину, нужно нажимать на газ, чтобы разогнаться до скорости 60 миль в час, первые несколько раз они в ней.
jpmc26
@ jpmc26 Когда я брал свои первые уроки вождения, меня просили наверняка проехать 30 км / ч, и я считаю, что этот урок также включал короткое расстояние со скоростью 50 км / ч. Это определенно больше, чем обычная карета. И то же самое касается git: вы, как правило, учитесь объединяться и объединяться с первого дня. Это неотъемлемая часть использования git. Избегайте этого, и вы злоупотребляете инструментом точно так же, как злоупотребляете автомобилем при скорости не более 15 км / ч.
Cmaster
-3

Если все работают над мастером, вы ничего не можете сделать. Вещи неизбежно испортятся.

Вы должны использовать мастер для готовых продуктов, которые отправляются клиенту. Вы должны использовать разработку для постоянного развития, и вы не должны позволять никому подталкивать к разработке. Стандарт заключается в том, что каждый разветвляется из dev, вносит свои изменения, переносит их из локальной в свою ветвь на сервере и выдает push-запрос. Затем кто-то просматривает изменения и объединяет их с разработкой.

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

Вы можете использовать sourcetree, например, чтобы сделать эту работу без какой-либо боли.

gnasher729
источник
4
Это просто замена «master» на «development», с дополнительным риском того, что люди не переключатся в ветку разработки после проверки по умолчанию. Я предпочитаю GitLab Flow , который является удачной средой между тяжелым GitFlow и редким GitHub Flow.
Сис Тиммерман
@CeesTimmerman Если вам не нравится Gitflow, вас может заинтересовать и Oneflow .
jpmc26