Как вы можете ошибиться с Git – и что делать вместо этого.

kak vy mozhete oshibitsya s git – i chto delat?v=1656520334

Я не могу присоединиться к удаленному хранилищу, позвольте мне произвести принудительное нажатие.

Позвольте мне запустить rebase в удаленном репозитории, чтобы сделать историю комитов более аккуратной.

Позвольте мне изменить мой предыдущий комит, который находится в удаленном хранилище.

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

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

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

Принудительно нажать на удаленное хранилище

vxvEY0Py6Tt3Jsfqcw3H5BSMdGC2qpuA2TqD
Фото Тима Моссхолдера на Unsplash

Скажем, два разработчика работают над одной веткой. Разработчик 2 – новичок в Git.

  1. Разработчик 1 завершил внесение изменений и перенес код в удаленное хранилище.
  2. Теперь Developer 2 завершил внесение изменений, но не может переместить код в удаленное хранилище.
  3. Разработчик 2 выполняет быстрый поиск в Google, узнает команду force push и использует ее. Команда есть git push -f
  4. Разработчик 1 проверяет удаленный репозиторий только для того, чтобы обнаружить, что написанный ими код полностью исчез.

Это происходит потому, что принудительное нажатие переопределяет код в удаленном хранилище и, следовательно, существующий код в удаленном хранилище теряется.

Идеальный способ решения этого сценария

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

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

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

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

Попытка перебазировать удаленный репозиторий

YYrwWwrW0Le9w89HoybfYPLmJ5JpmwwzABOG
«зеленый, красный и белый высоковольтный выключатель» от Бена Херши на Unsplash

Скажем, два разработчика работают над ветвью функций.

  1. Разработчик 1 совершил кучу комитов и перенес их в отдаленную ветвь функций.
  2. Разработчик 2 переносит последние изменения из удаленной ветви функций в ветвь локальных функций.
  3. Разработчик 2 добавляет кучу комиттов в локальную ветвь функций.
  4. Но разработчик 2 также желает убедиться, что последние конфигурации из ветки выпуска перебазируются в репозиторий функций. Поэтому Developer 2 перебазирует ветку выпуска на ветку локальной функции. Это перебазирование, выполненное из удаленного к локальному репо разных ветвей..
  5. Теперь Developer 2 пытается отправить код в удаленную ветвь функций. Git не позволит вам, поскольку история комиттов изменилась. Так что разработчик 2 сделает принудительный толчок.
  6. Теперь, когда разработчик 1 хочет извлечь последний код из удаленной ветви функций, это трудная работа, поскольку история комиттов изменилась. Поэтому разработчику 1 придется позаботиться о большом количестве конфликтов кода — даже о лишних конфликтах кода, о которых уже позаботился разработчик 2.

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

Идеальный способ решения этого сценария

Идеальный способ разрешения этой ситуации – это всегда перебазировать только локальное хранилище. Ни один из комитов в локальном репо не должен был уже перемещен в удаленное репо.

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

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

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

Rebase – очень мощная функция, но используйте ее осторожно.

Внесение изменений в комиты в удаленном хранилище

gq1Wo6a6yVlzmaudBN6xO6Vs65fZ7EkiYukn
«Сломанная керамическая плита на полу» от chuttersnap на Unsplash

Скажем, два разработчика работают над ветвью функций.

  1. Разработчик 1 сделал фиксацию и перенес его в удаленную ветвь функций. Давайте назовем это «осуществление стариком».
  2. Разработчик 2 извлекает последний код из удаленной ветви функций в ветвь локальной функции
  3. Разработчик 2 работает над кодом в локальном хранилище и еще не передал ни один код в удаленный репозиторий.
  4. Разработчик 1 осознает, что в комите произошла ошибка и вносит изменения в комит в локальном репо. Давайте назовем это «осуществление нового».
  5. Разработчик 1 пытается переместить измененный коммит в удаленную ветвь функций. Но Git не позволил бы этого, потому что в истории комитов изменились. Таким образом, Developer 1 производит принудительный толчок.
  6. Теперь, когда разработчик 2 хочет извлечь последний код из удаленной ветви функций, Git заметит разницу в истории комитов и создаст комит слияния. Когда разработчик 2 просмотрит историю фиксации в локальном репо, разработчик 2 заметит и «сделать новое», и «сделать старое». Это разрушает весь смысл внесения изменений в комит.
  7. Даже если Developer 2 выполнит перебазирование из удаленной ветки в локальную ветвь, «commit old» все равно будет присутствовать в локальной Developer 2. Поэтому это все равно будет частью истории комиттов.

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

Идеальный способ решения этого сценария

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

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

Hard reset

6JofEPRTTXtI2CQJvVYxKtSnV3NtdyL9TbBZ
«Прозрачное песочное стекло у розовых цветов» Натана Думлао на Unsplash
  1. Hard reset выполняется с помощью git reset --hard
  2. Есть также другие типы сброса--soft и --mixed которые не так опасны, как жесткий сброс

Скажем, разработчик 1 работает над ветвью функций и совершил пять комитов в локальном репо.

  1. Кроме того, Developer 1 сейчас работает над двумя еще не зафиксированными файлами.
  2. Если Developer 1 запущен git reset --hard <commit4hash> состоятся следующие вещи.
  3. Последним комитом в ветке функций теперь будет commit4, а commit5 потерян.
  4. Два незакрепленных файла, над которыми работал разработчик 1, также потеряно

Commit5 все еще существует внутри Git, но ссылка на него потеряна. Мы можем вернуть commit5 с помощью git reflog. Но, учитывая это, использовать жесткий сброс все еще очень рискованно.

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

Как узнать плохую практику при использовании Git

sa54At5X8hjGOHKzP2owlBAfmMuhkjIdpzOy
«Неоновая вывеска с вопросительным знаком» Эмили Мортер на Unsplash

Список, который я упоминал выше, не включает всего. Он лишь перечисляет некоторые вещи, которые могут пойти не столько при использовании Git.

Итак, как вы вообще знаете, чего следует избегать при использовании Git?

  1. Одна общая вещь, которую вы могли бы заметить в вышеприведенном списке, — это то, что проблемы возникают, когда в одной ветке работает несколько человек. Таким образом, использование правильных рабочих процессов Git гарантирует, что только один человек одновременно работает над одной ветвью функций. Веткой выпуска будет заниматься технический руководитель или старший разработчик. Этот рабочий процесс может предотвратить возникновение некоторых серьезных проблем.
  2. Еще одна общая вещь, которую вы могли бы заметить, – это использование силового толчка повсюду. Git по умолчанию гарантирует, что вы не можете вносить разрушительные изменения в удаленном репозитории. Но принудительное нажатие переопределяет поведение Git по умолчанию.
  3. Поэтому каждый раз, когда вы находитесь в положении, когда вам может понадобиться применить силу, используйте ее только в крайнем случае. Также оцените, есть ли другой способ добиться желаемого без применения силы.
  4. Любая операция, изменяющая историю фиксаций в удаленном хранилище, может быть опасна. Изменяйте историю фиксации только в вашем локальном хранилище. Но даже в локальном хранилище соблюдайте осторожность при использовании жесткого сброса.
  5. Использование рабочих процессов Git может быть лишним в очень крошечных проектах. В этих проектах несколько разработчиков будут работать на одной ветке. Но, прежде чем делать какие-либо серьезные изменения в удаленном хранилище, лучше один раз оценить, повлияет ли это на других разработчиков.

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

Об авторе

Я люблю технологии и слежу за достижениями в этой области. Мне тоже нравится помогать другим своим технологическим знаниям.

Не стесняйтесь связаться со мной в моем аккаунте LinkedIn https://www.linkedin.com/in/aditya1811/

Вы также можете подписаться на меня в Twitter https://twitter.com/adityasridhar18

Мой веб-сайт: https://adityasridhar.com/

Введение в Git

Как эффективно использовать Git

Как стать экспертом по git

Первоначально опубликовано на adityasridhar.com

Добавить комментарий

Ваш адрес email не будет опубликован.