В нашей повседневной разработке, когда мы сталкиваемся с неправильной работой хранилища git, как вовремя спастись, это кровавый урок. Я считаю, что каждый программист сталкивался с проблемами разной степени в большей или меньшей степени. Некоторые проблемы могут быть вызваны небрежным неправильным использованием, а некоторые могут быть проблемами личных способностей. Новички склонны к проблемам при использовании git. Поговорим о том, как избежать проблем с одной стороны, и как быстро справиться с этим, когда это происходит.
Избегайте ошибок персонала
- Прежде всего, необходимо стандартизировать набор процессов, чтобы несколько человек могли совместно использовать ветки git.Когда этот процесс знаком и запущен, проблем можно уменьшить соответствующим образом. Даже если есть проблема, ее можно быстро решить в соответствии с заранее заданным решением проблемы.
- Новые сотрудники должны стараться избегать выполнения некоторых операций слияния в первую неделю или две.Если они не знакомы с процессом использования git, им не следует их выполнять.
Спецификация процесса
С точки зрения процесса, это набор процессов, которые я составил в реальной разработке. Он может быть не таким совершенным. Если у вас есть лучшие предложения, вы можете сообщить мне об этом в комментариях.
Как правило, небольшая команда будет иметь ритм итераций, например, одну маленькую итерацию в неделю и две большие итерации, фиксированное время просмотра и фиксированное время выпуска каждую неделю.
В качестве примера возьмем наш текущий фактический ритм.Ритм представляет собой небольшую итерацию в неделю, большой сброс каждые две недели, требования для следующей итерации будут пересматриваться каждую пятницу, а версия будет выпускаться каждую среду. вышел в среду, и как бы ни был велик спрос, его нужно разбирать или заниматься отдельной версией.
Управление ветками: ответственный создаст ветку разработки из мастера.Например, следующая версия 0915, которая должна вытащить одну20210915-releaseКак ветвь обычной итеративной версии, каждый разработчик20210915-releaseВытяните собственную ветку разработки для кодирования и объединитесь с ней после завершения кодирования.20210915-releaseТест выпуска ветки, на этот раз切忌删除个人的开发分支, более поздняя обработка ошибок по-прежнему выполняется в собственной ветке разработки. По завершении теста вы можетеmasterИзвлеките ветку выпуска, вы также можете использовать текущую тестовую ветку для выпуска в среду оттенков серого.После прохождения проверки среды оттенков серого при подтверждении того, что выпуск находится в сети, укажитеmerge requestответственному лицу,masterПосле этого нажмитеtag, и, наконец, используйтеtagПубликация в онлайн-среде.
这里使用提 merge request 的方式，就是为了保证 master 代码的安全，尽可能的避免误操作了 master 的代码
Обработка нестандартных ситуаций: когда возникает нештатная ситуация, требующая приостановки отдельных требований в процессе разработки, мы запускаем нештатный процесс, например (20210915-release), отбросить текущую нормальную ветвь итерации и перезапуститьmasterпотяните итеративную ветвь (20210915-release-01), а затем каждый разработчик объединяет свой обычный онлайн-код в20210915-release-01, код, который приостанавливает выполнение требования, не включен, выпустите тест,
Проведите общий регрессионный тест и пройдите обычный процесс выпуска после прохождения.
Как быть с ситуацией неправильной ветки
Например 🌰 при объединении ветвей ошибочно пропускает ненужную строкуcommitЯ влился в целевую ветку, как мне выйти из нее?
сбросить выбранную фиксацию (commitпредставленоoriginСлучай)
Например:内容修改222、内容修改333、内容修改444Эти три коммита не то, что я хочу, как убрать эти коммиты.
проверил内容修改111, щелкните правой кнопкой мыши
проверил强行合并-丢弃所有工作副本改动, нажмите确认
продолжайте нажимать确认
сбросить коммит на
内容修改111коммит, в настоящее время, поскольку эта операция сброса действует только в локальной области временного хранилища, исходная сторона не изменилась, поэтому она находится на три коммита позади исходной стороны.
Примечание. В это время вы столкнетесь с проблемой, всегда показывая несколько коммитов за источником, когда вы вытащите из источника, вы вернетесь к исходной ошибке неправильной работы. Как бы вы это ни делали, это неправильно, особенно когда это связано с большим количеством изменений файлов, вы не можете определить, какой код является ненужным, а новые проблемы возникнут.
Не паникуйте, это потому, что вы пропускаете вторую половину операции, сконцентрируйтесь и посмотрите вниз
проверил内容修改444Отправить, щелкните правой кнопкой мыши
выбрано на этот раз软合并-保持所有本地改动Опции
После завершения операции,souretreeпредставлен следующим образом,originконец очищен内容修改222、内容修改333、内容修改444Представленный контент и локальное отражение соответствующих изменений. Нажмите «Отправить», чтобы по ошибке удалить три отправки.
Резюме: в первый раз, чтобы сбросить целевую запись фиксации, которую вы хотите откатить, необходимо выбрать режим использования.强行合并-丢弃所有工作副本改动Второй сброс выбран последней записи фиксации, режим использования (рекомендуется)软合并-保持所有本地改动
сбросить выбранную фиксацию (commitхранится локально)
В случае, когда фиксация хранится локально, я хочу сбросить на
test111Отправить, выбрать фиксацию, щелкнуть правой кнопкой мыши
На данный момент вы успешно вернулись к коммиту, который хотите сбросить,test222 test333Представлено и возвращено в местную зону развития
Эта операция достигает намеченной цели и возвращается к указанному представлению. Еще одним преимуществом является то, что на стороне происхождения нет записи о ваших ошибках, и ваш лидер не может ее видеть, что можно охарактеризовать как уничтожение трупа. Это не только решает проблему, но и не позволяет другим обнаружить ваши ошибки.
Вывод: мы можем частоcommitЛокальные изменения вносятся в локальную промежуточную область и передаются в локальную промежуточную область только при необходимости.originконец
Выбранная ветвь вытягивания коммита
Этот подход относится кtest111Отправьте предыдущий код и возьмите одну ветку, а затем скопируйте соответствующий исходный код, затем переключите ветку обратно на ветку с проблемой и вытащите исходный код, скопированный из новой ветки.覆盖Соответствующий исходный код ветки проблемы, в это время локальная среда IDE может четко видеть измененные файлы и отправлять их для решения проблемы. Такое решение — это решение, которое обычные люди могут быстро понять, хотя оно немного глупое и грубое.
Просмотр всех журналов изменений файла
Выберите соответствующий файл, нажмите еще раз, выберите查看选中的修改日志..., то есть можно наглядно представить все записи изменений этого файла, чтобы избежать случайного сброса среди коллег.
напиши в конце
Если вы хотите делать хорошую работу, вы должны сначала заточить свои инструменты