Skip to content

Latest commit

 

History

History
223 lines (138 loc) · 18.5 KB

1.2.2 Git.md

File metadata and controls

223 lines (138 loc) · 18.5 KB

Git

Как изучать?

1) Про Git для новичков ссылка

Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день его поддерживает Джунио Хамано.

Для каждого коммита гит запоминает слепок (снимки) изменившихся файлов целиком. DATA

Архитектура систем контроля версий (от англ. Version Control System, VCS)

Open

Инструменты VCS имеют два основных типа удаленной архитектуры:

  • централизованный (Centralized VCS); Примеры таких систем: SVN, CVS.
alt text
  • распределенный (Distributed model); Примеры таких систем: Git, Mercurial. Git имеет распределенную модель архитектуры, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в папках на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн. Это облегчает работу над одним проектом для нескольких людей. Для такой работы используются сайты вроде github и bitbucket.
alt text 
Родительский коммит - тот, от которого пошли разделения на ветки.
Имя основной ветки по умолчанию в Git — master или main.

Состояния файлов Git

Open

Файл в Git может находится в одном из трёх состояний:

alt text
  • untracked (:white_circle:) — не добавлен в индекс для коммита, не вошли в последний спапшот и не подготовлены к коммиту.
  • modified (:red_circle:) - объекты поменяли, но еще не зафиксировались.
  • staged (:green_circle:) — добавлен в индекс для включения в коммит.
  • commited (:white_circle:) — объект уже сохранен на базе.

2) Gitflow

Open

Существуют различные модели ветвления, наиболее популярные:

alt text alt text alt text

Базовые принципы популярных моделей ветвления

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

Pull Request

Open

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

Запрос на слияние (Pull-Request - BitBucket, Merge request - Gitlab) – механизм системы контроля версий, позволяющий оформить изменения из ветки в виде предложения к слиянию в основную (или какую-то иную) ветку репозитория.

alt text

Что даёт:

  • Описание предлагаемого изменения видно в интерфейсе системы контроля версий всем заинтересованным участникам

  • Возможность провести code review и оставить комментарии ещё до включения изменений в целевую ветку

  • Возможность не допустить слияния, пока не будут выполнены все необходимые условия

    Например: * Минимальное количество подтверждений от участников, проводящих ревью * Успешно прошедшая сборка в системе CI * Отсутствие критичных замечаний по результатам автоматического статического анализа

3) Правила написания коммит сбщ

Спецификация Conventional Commits 1.0.0 для добавления понятного человеку и машине значения о фиксации сообщения. Вкратце:

Коммит содержит следующие структурные элементы, чтобы сообщить о намерении потребителям вашей библиотеки:

  • fix: фиксация типа fix исправляет ошибку в вашей кодовой базе (это соответствует PATCH семантическому управлению версиями).

  • feat: фиксация такого типа feat вводит новую функцию в кодовую базу (это коррелирует с MINOR семантическим управлением версиями).

  • BREAKING CHANGE: фиксация, имеющая нижний колонтитул BREAKING. CHANGE: или добавляющая !после типа/области действия, вносит критическое изменение API (соответствует MAJOR семантическому управлению версиями). BREAKING CHANGE: может быть частью коммита любого типа.

  • Допускаются типы, отличные от fix: и feat: (н/р: основанные на Angular convention) рекомендуется build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, и др.

Дополнительные типы не предусмотрены спецификацией Conventional Commits и не имеют неявного эффекта в Semantic Versioning (если только они не содержат BREAKING CHANGE). Для предоставления дополнительной контекстной информации к типу фиксации может быть добавлена область видимости, которая заключена в круглые скобки, например, feat(parser): добавить возможность разбора массивов.

Conventional Commits 1.0.0 спецификация сопряжена с SemVer (Semantic Versioning Specification).

4) Команды

Open

  • git fetch и git pull:

git fetch Получает список изменений в удаленном репозитории, а также сами изменения, без слияния с вашими изменениями;

git pull получает изменения из удалённой ветви и сливает их со текущей ветвью (выполняет git fetch и git merge origin/[your branch]),

  • git diff - просмотр неотслеживаемых изменений

  • git add - добавляет файлы в отслеживаемые. -A - флаг для добавления всех измененных файлов; git rm --cached (file) - удаляет из отслеживаемых файлов (без флага --cached удаляет файлы, которые уже закоммичены).

  • git show [commit_id] - показывает изменения этого коммита.

  • git push - отправляет изменения в удаленный репозиторий. Пушит все, кроме тегом, для тегов использовать флаг --tag.

  • git commit --amend -m "" - добавляет изменения к предыдущему коммиту, не создавая новый, при это хеш меняется&

Опции:

  • git commit --amend --allow-empty -m "New" - Бывает, что нужно исправить опечатку в комментарии к последнему коммиту, не затрагивая файлов В этом случае удобно воспользоваться флагом allow-empty, чтобы гит не ругался на отсутствие изменений для коммита;
  • git commit --amend --no-edit - Не добавляет новый коммит, оставляет старый, при этом не запускает редактор Если ветка уже запушена, то после этой команды нужно прописать git push -f и удалённая ветка будет перезаписана;

  • git merge - это 1/2 утилит Git, которая специализируется на интеграции изменений из одной ветки в другую. Сливание двух веток в одну

  • git rebase - это 2/2 утилит Git, которая специализируется на интеграции изменений из одной ветки в другую. (Меняет всю историю ваших коммитов вместе с хешами, поэтому если вы работаете вдвоем, то чревато ошибками). Git merge в этом плане безопаснее, когда работает несколько человек над одной веткой)

Опции:

  • pick — оставляет текущий коммит без изменений;
  • squash — соединяет текущий коммит с верхним в интерактивном виме или с предыдущим в дереве коммитов;
  • fixup — то же самое, что и squash, но отбрасывает commit message этого коммита;
  • reword — измение сообщение коммита. Вместо pick пишем r и выходим из вима с сохранением, появляется интерактивное окно, где нам предлагают поменять текст;
  • drop — удалить коммит. Могут быть проблемы с тем, что мы дальше меняли файл после того как удалили;
  • reset — жестко меняем HEAD на новый (вся последующая история после того, на что мы сделали reset - не сохраняется);

  • git blame (file) - показывает кто, когда, какую строчку кода написал/изменил

  • git grep "test" - ищет в рабочем каталоге слово test (как в коде, так и в названии файлов)

  • git log - просмотр истории коммитов. По умолчанию git log вывод в таком формате:

alt text

Более удобный формат: git log --graph --oneline --decorate --stat

Опции:

  • --stat — выведет статистику для каждого коммита;
  • --graph — выводит дерево зависимостей для всех коммитов;
  • --decorate — покажет “головы” (HEAD);
  • --all — покажет все ветки;
  • -- oneline - выводит сокращённые данные коммита (в виде одной строки);
  • git reflog - показывает ссылки (reference logs) на все изменения в гите, поскольку во время вашей работы при переключении веток и коммитов изменений Git записывает все изменения HEAD в reflog (и хранит даже удаленные). git log в свою очередь хранит только историю существующих коммитов.

В какой-то момент при работе с Git вы можете нечаянно потерять коммит. Как правило, такое случается, когда вы удаляете ветку, в которой находились некоторые наработки, а потом оказывается, что они всё-таки были нужными; либо вы выполнили git reset --hard / git rebase --onto develop без указания HEAD~n, тем самым отказавшись от коммитов, которые затем понадобились. git reflog - помогает восстановить изменения в таком случае.

  • git stash - позволяет сохранить изменения в temporary-архив гита, сделанные в рабочей копии, чтобы вы могли применить их позже.

Опции:

  • git stash сохраняет изменения (индексированные и неиндексированные) в отдельном хранилище;
  • git stash save "comment" сохраняет изменения с комментарием;
  • git stash pop возвращает изменения. По умолчанию команда git stash pop применяет последний набор отложенных изменений: git stash pop stash@{0};
  • git stash list список изменений, помещенных в shash хранилище;
  • git stash drop stash@{1} - удаляет сохраненные измения stash@{1}. git stash clear удаляет все наборы отложенных изменений;

5) Мои конфигурации Git

5.1) Хук для проверки связанности commit msg с номером задачи: ссылка

5.2) Чтобы применить мои конфигурации к себе нужно: содержимое файла gitconfig поместить в ~/.gitconfig

P.S.:

[1] origin: git remote -v

[2] git fetch [remote-name]

1.2.1 Markdown Them Folder | Back To iOSWiki Contents | 1.2.3 GitFlow Theme