5 вещей, которые я хотел бы знать о Git

5 вещей, которые я хотел бы знать о Git Изучение

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

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

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

1. Четыре этапа

Благодаря использованию CVS в качестве системы управления версиями (старый пример системы контроля версий (VCS)) одной из самых непонятных вещей в git был его другой подход к состоянию контента.

В CVS было два состояния данных:

  • незавершенный
  • преданный идее

В CVS было два состояния данных

В то время как git имеет четыре состояния :

  • Локальные изменения
  • Поэтапные / добавленные изменения
  • Преданный идее
  • На удаленный

Если вы, как и я, используете git commit

Если вы, как и я, используете git commit -am «checkin message» для фиксации своей работы, то второе состояние «добавление / постановка» для вас более или менее невидимо. Вместо -aэтого он сделает это за вас. По этой причине я призываю новых пользователей опускать -aфлаг git addвручную, чтобы они поняли эти различия.

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

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

Отсюда следует еще один ключевой момент: все репозитории git созданы равными.

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

Читайте также:  Аутсорсинг веб-разработки: плюсы и минусы

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

Это приводит к гораздо более гибкому, но потенциально более сложному рабочему процессу

2. Что такое ссылка?

Документы и блоги Git продолжают говорить о ссылках, но что такое ссылка?

Ссылка — это просто указатель на фиксацию. А фиксация — это уникальная ссылка на новое состояние контента.

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

HEAD является ссылкой на «где вы находитесь» в истории контента. Это контент, который вы сейчас просматриваете в своем репозитории git.

Когда ты git commit, то HEADпереходит на новый коммит.

git tagСсылка один, который может иметь произвольный текст, и не двигается, когда новый коммит видно.

A git branch- это ссылка, которая перемещается вместе с HEADэлементом всякий раз, когда вы фиксируете новое изменение.

Тогда прояснится еще пара непонятных вещей. Например, detached HEADнечего паниковать, несмотря на его страшное название — это просто означает, что ваш HEADне указывает на ветку.

Взгляните на эту диаграмму:

Он представляет собой серию коммитов

Он представляет собой серию коммитов.

Что сбивает с толку, на диаграммах git стрелки идут назад во времени. A- это первая фиксация, затем Bи так до последней фиксации ( H).

Есть три references- master(который указывает на C), experimentalкоторый указывает на H, и HEAD, который также указывается H. Помните, по HEADсути, означает «где мы находимся».

3. Что такое перемотка вперед?

Теперь, когда вы понимаете, что такое HEADссылка, понять, что такое перемотка вперед, довольно просто.

Обычно, когда вы объединяете две ветки вместе, вы получаете новый коммит:

На приведенной выше диаграмме Iэто фиксация

На приведенной выше диаграмме Iэто фиксация, представляющая слияние своего общего предка ( ) Hи Gот него D. Изменения, сделанные в обеих ветвях, применяются вместе, Dа результирующее состояние содержимого после фиксации сохраняется в новом состоянии ( I).

Но рассмотрим диаграмму, которую мы видели выше:

Но рассмотрим диаграмму, которую мы видели выше

Там у нас две ветки, но ни в одну из них изменений не вносили. Допустим, мы хотим объединить изменения на experimental( Eи H) в master- мы поэкспериментировали, и эксперимент прошел успешно.

В этом случае слияние Eи Hв мастер не требует никаких изменений по сравнению с H, поскольку у нас нет Fи Gизменений, которые должны быть объединены вместе с Eи H. Все они находятся в одной линии изменений.

Читайте также:  Тенденции разработки программного обеспечения в 2021

Такое слияние требует только, чтобы masterссылка была взята и перемещена из Cв H. Это «перемотка вперед» — ссылка просто должна двигаться вперед, и согласовывать содержимое не нужно.

4. Что такое Rebase?

Моя страница руководства для git rebase говорит:

«Повторное нанесение коммитов поверх другого базового наконечника».

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

Наглядный пример делает это намного понятнее.

Наглядный пример делает это намного понятнее

Вы можете слиться feature1с masterветкой, и в итоге вы получите новый commit ( G), который сделает дерево таким:

Вы можете слиться feature1с masterветкой, и в итоге вы получите новый commit

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

А. git rebaseиспользует другой подход. Это поднимает «изменения на нашей отрасли (совершающий Dна feature1в данном случае) и применяет его к концу ветви мы на ( HEADнаходится master).

Это выглядит намного аккуратнее, не так ли? master теперь можно «быстро переадресовать» туда, где он feature1находится, перемещая masterуказатель на D.

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

5. Возможности git log

Все вышеперечисленные концепции интересны, но как вы можете использовать их в повседневной работе?

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

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

$ git log --oneline --graph

$ git log --oneline --graph --simplify-by-decoration --all
  • oneline предписывает журналу показывать только идентификатор фиксации и комментарий для каждой фиксации
  • graph обеспечивает визуализацию структуры прямо в вашем терминале
  • simplify-by-decoration удаляет все незначительные изменения из истории git, позволяя вам видеть все крупные события в истории проекта

Оцените статью
bestprogrammer.ru
Добавить комментарий