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

kak stat ekspertom git?v=1656527414

Я совершил ошибку в своем комитете, как мне это исправить?

Моя история комитов беспорядочна, как сделать ее аккуратнее?

Если у вас когда-либо возникали вышеперечисленные вопросы, то эта публикация для вас. Эта публикация включает список тем, которые сделают вас экспертом Git.

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

Я совершил ошибку в своем комитете. Что я должен сделать?

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

Сценарий 1

Скажем, вы зафиксировали кучу файлов и поняли, что введенное вами сообщение о фиксации действительно непонятно. Теперь вы хотите изменить сообщение о фиксации. Для этого можно воспользоваться git commit --amend

git commit --amend -m "New commit message"

Сценарий 2

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

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

git add file6
git commit --amend --no-edit

--no-edit означает, что сообщение о фиксации не меняется.

Сценарий 3

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

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

git config user.email "your email id"

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

git commit --amend --author "Author Name <Author Email>"

Примечание

Использовать amend команда только в вашем локальном хранилище. Использование amend ибо удаленный репозиторий может создать большую неразбериху.

Моя история комитов – беспорядок. Как мне справиться?

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

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

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

Kf0bCgSdXtM1PJTZwn1FJ5-xPxJa7a3aSRZQ
Вот как будет выглядеть история комиттов в вашем локальном хранилище.

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

Вот где перебазировать приходит на помощь.

Что такое перебазирование?

Разрешите объяснить это на примере.

HeXMQ3fwvXGfqiBCQJpYCRmzMTGkObShA4NS
Эта диаграмма показывает комиты в ветке выпуска и вашей ветке функций
  1. Ветвь Release имеет три комита: Rcommit1, Rcommit2 и Rcommit3.
  2. Вы создали свою ветвь Feature из ветки Release, когда она имела только одну фиксацию, то есть Rcommit1.
  3. Вы добавили два комита к ветке Feature. Это Fcommit1 и Fcommit2.
  4. Ваша цель – переместить комиты из ветки Release в ветвь Feature.
  5. Для этого вы собираетесь использовать rebase.
  6. Пусть будет название ветки Release увольнение и имя ветки Feature be особенность.
  7. Перебазирование можно выполнить с помощью следующих команд:
git checkout feature
git rebase release

Перебазирование

При перебазировании ваша цель – убедиться, что ветвь Feature получает последний код из ветви Release.

Rebasing пытается добавить каждую фиксацию один за другим и проверяет наличие конфликтов. Это звучит запутано?

Объясню с помощью диаграммы.

Это показывает, что действительно делает перебазирование внутри:

iGgX4jvJOB8Gc2n8T1WSh8VpWEZqd1CoL2g3

Шаг 1

  1. В момент, когда вы запускаете команду, ветвь Feature указывается на заголовок ветки Release.
  2. Теперь в ветке Feature есть три комита: Rcommit1, Rcommit2 и Rcommit3.
  3. Возможно, вам интересно, что произошло с Fcommit1 и Fcommit2.
  4. Комиты все еще существуют и будут использоваться на следующих шагах.

Шаг 2

  1. Теперь Git пытается добавить Fcommit1 в ветвь Feature.
  2. Если конфликта нет, Fcommit1 добавляется после Rcommit3
  3. Если возникнет конфликт, Git сообщит вам, и вам придется разрешить конфликт вручную. После разрешения конфликта воспользуйтесь следующими командами, чтобы продолжить перебазирование
git add fixedfile
git rebase --continue

Шаг 3

  1. После добавления Fcommit1 Git попытается добавить Fcommit2.
  2. Опять же, если нет конфликта, Fcommit2 добавляется после Fcommit1 и перебазирование проходит успешно.
  3. Если возникнет конфликт, Git сообщит вам, и вам придется решить его вручную. После разрешения конфликтов используйте те же команды, которые описаны в шаге 2
  4. После того, как полное перебазирование будет выполнено, вы заметите, что в ветке Feature есть Rcommit1, Rcommit2, Rcommit3, Fcommit1 и Fcommit2.

Важные моменты

  1. И Rebase, и Merge полезны в Git. Один не лучше другого.
  2. При слиянии у вас будет фиксация слияния. В случае перебазирования нет дополнительных комитов, таких как комиты слияния.
  3. Одной из лучших практик является использование команд в разных точках. Используйте rebase при обновлении локального хранилища кода последним кодом из удаленного хранилища. Используйте слияние, когда вы имеете дело с запросами на подъемник, чтобы объединить ветку Feature назад с ветвью Release или Master.
  4. Использование Rebase изменяет историю комиттов (это делает ее более аккуратной). Но, учитывая это, изменение истории комитов имеет свои риски. Поэтому убедитесь, что вы никогда не используете rebase для кода в удаленном хранилище. Всегда используйте rebase только для изменения истории фиксации локального кода репо.
  5. Если перебазировать в удаленный репозиторий, это может создать большую неразбериху, поскольку другие разработчики не распознают новую историю.
  6. Кроме того, если перебазирование выполняется в удаленном хранилище, это может создать проблемы, когда другие разработчики попытаются извлечь последний код из удаленного хранилища. Поэтому я снова повторяю, всегда используйте rebase только для локального хранилища?

Приветствую ?

Теперь вы эксперт Git?

В этой публикации вы узнали о:

Оба эти понятия очень полезны. Исследуйте мир Git, чтобы узнать больше.

Об авторе

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

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

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

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

Лучшие методы использования Git

Введение в Git

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

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

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