Git Crash Course

Суть

Тут решение всех, абсолютно, базовых вопросов которые могут встретиться в работе с гитом. Начнем с базы, для понимания работы ( очень нужно для решения вопросов: а что я на ветку переключиться не могу ) и продолжим уровнем стешей, черепиков и прочего.

Полезные ссылки

Содержание

Основы

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

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

Полная долгосрочная история изменений каждого файла. Это означает, что сохраняются все изменения, сделанные разными разработчиками на протяжении многих лет. Изменения включают создание и удаление файлов, а также редактирование их содержимого. Разные инструменты VCS по-разному справляются с переименованием и перемещением файлов. История должна также включать автора, дату и пояснения к каждой модификации. Полная история позволяет вернуться к предыдущим версиям для анализа причин возникновения ошибок и является важной при необходимости исправления проблем в старых версиях программного обеспечения. Если над программой активно работают, практически любую версию можно считать «старой».
Ветвление и слияние. Совместная работа членов команды — это очевидное требование, но даже отдельные разработчики могут извлечь пользу из возможности работать над независимыми потоками изменений. Создание «ветки» в инструментах VCS позволяет поддерживать независимость нескольких потоков работы, одновременно предоставляя возможность объединить их, чтобы убедиться, что изменения не конфликтуют между собой. Многие команды разработчиков применяют практику создания веток для каждой новой функции или версии программы. Существует множество различных рабочих процессов, которые команды могут выбирать при использовании ветвления и слияния в VCS.
Прослеживаемость. Возможность отслеживать каждое изменение, внесенное в программное обеспечение, и связывать его с системами управления проектами и отслеживания ошибок, такими как Jira, а также добавлять к каждому изменению сообщение с описанием его цели и намерений, может помочь не только в анализе первопричин и других расследованиях. Наличие аннотированной истории кода под рукой, когда вы читаете код и пытаетесь понять, что и почему он делает, позволяет разработчикам вносить правильные и согласованные изменения, соответствующие долгосрочному замыслу системы. Это особенно важно при работе с унаследованным кодом и критично для точного планирования будущей работы.

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

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

Mercurial: Mercurial — это распределенная система контроля версий с архитектурой, похожей на Git. Однако она имеет более централизованный подход и не использует хеши для отслеживания изменений.
Subversion: Subversion — это централизованная система контроля версий, которую часто сравнивают с Git. Хотя обе системы поддерживают ветвление и слияние, Subversion требует центрального сервера для управления репозиторием.
Perforce: Perforce — это коммерческая система контроля версий, предназначенная для крупных проектов разработки. Она использует централизованный подход и обладает такими функциями, как автоматизация сборок и отслеживание задач.
CVS: CVS — это более старая система контроля версий, которая все еще используется. Однако ей не хватает многих современных функций, и она часто считается устаревшей.

Установка git

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

На Windows: Скачайте установочный файл с официальной страницы Git и следуйте инструкциям по установке.
На macOS (с использованием Homebrew): Введите команду brew install git в терминале.

После установки вы можете проверить версию Git, введя команду git --version в терминале. Это отобразит текущую версию установленного Git.

Что такое репозиторий

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

Можно узнать детальнее на сайте GitHub Ссылка

Введение и команды GIT

git init

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

Документация по оциям можно прочитать на оифициальном сайте GIT


git init [-q | --quiet] [--bare] [--template=<template-directory>]
      [--separate-git-dir <git-dir>] [--object-format=<format>]
      [--ref-format=<format>]
      [-b <branch-name> | --initial-branch=<branch-name>]
      [--shared[=<permissions>]] [<directory>]

--------------------------------------------------------------------------------
~ » mkdir gitDterraCrash                               ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~ » cd gitDterraCrash                                  ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash » git init                            ntcad@Mishas-MacBook-Air

Initialized empty Git repository in /Users/ntcad/gitDterraCrash/.git/
--------------------------------------------------------------------------------
~/gitDterraCrash (main) »                              ntcad@Mishas-MacBook-Air

git config

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

Самый простой сценарий использования git config — это вызов команды с именем конфигурации, которая отобразит установленное значение для этого имени. Имена конфигураций представляют собой строку, разделённую точками, и состоят из «раздела» и «ключа» в зависимости от их иерархии. Например: user.email.

Уровни конфигурации и файлы в Git

Прежде чем обсуждать дальнейшее использование команды git config, давайте рассмотрим уровни конфигурации. Команда git config может принимать аргументы, чтобы указать, с каким уровнем конфигурации нужно работать. Доступны следующие уровни конфигурации:

\ **Локальный уровень (Local)**Этот уровень относится к конфигурации конкретного репозитория. Файл конфигурации хранится в .git/config в корневой директории репозитория. Параметры, установленные на локальном уровне, применяются только к этому проекту.

Пример:

bash git config --local user.name "Your Name" 2. \ **Глобальный уровень (Global)**Конфигурация на глобальном уровне действует для всех репозиториев пользователя на данном компьютере. Файл конфигурации хранится в домашней директории пользователя в файле ~/.gitconfig или ~/.config/git/config.

Пример:

bash git config --global user.email "your.email@example.com" 3. \ **Системный уровень (System)**Этот уровень конфигурации действует для всех пользователей на компьютере и хранится в файле /etc/gitconfig. Параметры, установленные на системном уровне, применяются ко всем репозиториям всех пользователей на системе.

Пример:

bash git config --system core.editor "vim" 4. \ **Уровень рабочего каталога (Worktree)**Используется для установки конфигурации, специфичной для конкретного рабочего каталога. Файл конфигурации хранится в .git/config.worktree.

Приоритеты уровней

Если один и тот же параметр установлен на нескольких уровнях, Git будет использовать значение с самого низкого уровня (локальный > глобальный > системный).

Пример команды для просмотра текущих конфигураций:


git config --list

git config, обязательная настройка при установке гита

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

--------------------------------------------------------------------------------
~/gitDterraCrash (main) » git config --global user.email "kovalev@dterra.ru"
--------------------------------------------------------------------------------
~/gitDterraCrash (main) » git config --global user.name "ntcad"
--------------------------------------------------------------------------------

Области в гите

Рабочая директория

Рабочая директория в Git — это локальная среда, где хранятся и изменяются файлы проекта. Она отражает текущее состояние файлов проекта, позволяя разработчикам редактировать, добавлять или удалять файлы. Изменения, внесённые в рабочую директорию, могут быть подготовлены для фиксации (commit), что означает, что они готовы к включению в следующий коммит. Рабочая директория связана с репозиторием Git и помогает управлять различиями между зафиксированной историей и текущим состоянием файлов. Она играет ключевую роль в отслеживании изменений, тестировании и разработке новых функций.

Область индексирования (Staging Area)

В Git область индексирования служит промежуточным этапом между изменениями в локальном репозитории и фактическим коммитом.

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

Фиксация изменений (Committing Changes)

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

![[environments.png]]

git add

Команда git add добавляет изменения в рабочем каталоге в область подготовки (staging area). Она сообщает Git, что вы хотите включить обновления в конкретный файл в следующий коммит. Однако git add на самом деле не оказывает значительного влияния на репозиторий — изменения не записываются, пока вы не выполните команду git commit.

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


git add <file>

Проиндексировать все изменения в файле для следующего коммита.


git add <directory>

Проиндексировать директорию для следующего коммита.


git add -p

Начать интерактивную сессию индексации, которая позволяет выбрать части файла для добавления в следующий коммит. Вам будут показаны изменения в виде фрагментов, после чего вас попросят ввести команду. Используйте y, чтобы проиндексировать фрагмент, n, чтобы пропустить, s, чтобы разбить его на более мелкие фрагменты, e, чтобы вручную отредактировать фрагмент, и q, чтобы выйти.


git add *

Проиндексировать все файлы для следующего коммита.

git commit

Команда git commit фиксирует снимок текущих изменений, находящихся в стадии подготовки (staged changes). Зафиксированные снимки можно считать "безопасными" версиями проекта — Git никогда не изменит их, если вы явно не попросите об этом.

Перед выполнением команды git commit используется команда git add, чтобы продвинуть или "подготовить" изменения в проекте, которые будут сохранены в коммите. Эти две команды, git commit и git add, являются одними из самых часто используемых.


git commit

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


git commit -a

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


git commit -m "commit message"

Команда для быстрого создания коммита с переданным сообщением коммита. По умолчанию, git commit откроет локально настроенный текстовый редактор и предложит ввести сообщение коммита. Передача опции -m позволит пропустить этот шаг и ввести сообщение напрямую.


git commit -am "commit message"

Команда для продвинутых пользователей, которая объединяет опции -a и -m. Эта комбинация сразу создаёт коммит всех отслеживаемых изменений и позволяет задать сообщение коммита напрямую.


git commit --amend

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

git remote

Команда git remote позволяет создавать, просматривать и удалять соединения с другими репозиториями. Удалённые подключения больше похожи на закладки, а не на прямые ссылки на другие репозитории. Вместо того чтобы обеспечивать доступ в реальном времени к другому репозиторию, они служат удобными именами, которые можно использовать для обращения к неудобным URL-адресам.

Например, на следующей схеме показаны два удалённых подключения из вашего репозитория: одно к центральному репозиторию, а другое — к репозиторию другого разработчика. Вместо использования их полных URL-адресов можно передавать команды, используя сокращённые имена origin и john.

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


git remote add <name> <url>

Создаёт новое подключение к удалённому репозиторию. После добавления удалённого репозитория вы сможете использовать <name> в качестве удобного ярлыка для <url> в других командах Git.


git remote rm <name>

Удаляет подключение к удалённому репозиторию с именем <name>.


git remote rename <old-name> <new-name>

Переименовывает удалённое подключение с <old-name> на <new-name>.

![[01.svg]]

[!info] Когда вы клонируете репозиторий с помощью команды git clone: Автоматически создаёт удалённое подключение под названием origin, которое указывает на клонированный репозиторий. Это удобно для разработчиков, создающих локальную копию центрального репозитория, так как предоставляет простой способ для получения изменений из исходного репозитория или публикации локальных коммитов. Именно поэтому большинство проектов, основанных на Git, называют свой центральный репозиторий origin

git push

Команда git push используется для загрузки содержимого локального репозитория в удалённый репозиторий. Пушинг — это способ передачи коммитов из локального репозитория в удалённый. Это противоположно команде git fetch, которая импортирует коммиты в локальные ветки, в то время как git push экспортирует коммиты в удалённые ветки. Удалённые ветки настраиваются с помощью команды git remote. Пушинг имеет потенциал перезаписать изменения, поэтому при его использовании следует соблюдать осторожность.


git push <remote> <branch>

Запушить указанную ветку, вместе со всеми необходимыми коммитами и внутренними объектами. Это создаст локальную ветку в целевом репозитории. Чтобы предотвратить перезапись коммитов, Git не позволит вам выполнить push, если это приведёт к конфликту с необходимостью небыстрого слияния (non-fast-forward merge) в целевом репозитории.


git push <remote> --force

Та же команда, что и выше, но с принудительным пушем, даже если это приведёт к небыстрому слиянию (non-fast-forward merge). Не используйте флаг --force, если вы не уверены в своих действиях.

Запушить все ваши локальные ветки в указанный удалённый репозиторий.


git push <remote> --tags

Теги не отправляются автоматически при пуше ветки или использовании опции --all. Флаг --tags отправляет все ваши локальные теги в удалённый репозиторий.

.gitignore

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

Git рассматривает каждый файл в вашей рабочей копии как один из трёх типов:

Отслеживаемый (tracked) — файл, который был ранее добавлен в область индексирования или зафиксирован;
Неотслеживаемый (untracked) — файл, который не был добавлен в область индексирования или зафиксирован;
Игнорируемый (ignored) — файл, который Git был явно проинструктирован игнорировать.

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

кэши зависимостей, такие как содержимое каталогов /node_modules или /packages;
скомпилированный код, такие как файлы .o, .pyc и .class;
каталоги с результатами сборки, такие как /bin, /out или /target;
файлы, создаваемые во время выполнения, такие как .log, .lock или .tmp;
скрытые системные файлы, такие как .DS_Store или Thumbs.db;
персональные конфигурационные файлы IDE, такие как .idea/workspace.xml.

Тема силшком большая, поэтому, если вы захотите узнать больше, воспользуйтесь данным ресурсом

Git ignore patterns

Пример файла и основных правил:

# В этом файле можно оставлять комментарии
# Имя файла .gitignore
# Файл нужно создать самостоятельно

# Каждая строчка — это шаблон, по которому происходит игнорирование

# Игнорируем файл в любой директории проекта
access.log

# Игнорируем директорию в любой директории проекта
node_modules/

# Игнорируем каталог в корне рабочей директории
/coverage/

# Игнорируем все файлы с расширением sqlite3 в директории db
# При этом не игнорируются такие же файлы внутри любого вложенного каталога в db
# Например, /db/something/lala.sqlite3
/db/*.sqlite3

# Игнорировать все .txt файлы в каталоге doc/ на всех уровнях вложенности
doc/**/*.txt

Первая практика

Давайте создадим пару файлов и начнем работу с гит

--------------------------------------------------------------------------------
~/gitDterraCrash (main) » echo "1" > file1.txt         ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » echo "2" > file2.txt        ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » echo "3" > file3.txt        ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » ls                          ntcad@Mishas-MacBook-Air

file1.txt file2.txt file3.txt
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) »                             ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » git add .                   ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » git commit -m "Initial fiels"
[main (root-commit) 68ef6ec] Initial fiels
 3 files changed, 3 insertions(+)
 create mode 100644 file1.txt
 create mode 100644 file2.txt
 create mode 100644 file3.txt
--------------------------------------------------------------------------------
~/gitDterraCrash (main) »                              ntcad@Mishas-MacBook-Air

Теперь опубликуем все наши наработки в gitlab

Заходим в GitLab ![[CleanShot 2024-09-14 at 23.38.01@2x.png]]
Создадим репозиторий в GitLab ![[CleanShot 2024-09-14 at 23.38.17@2x.png]]
Заполним все поля ![[CleanShot 2024-09-14 at 23.38.22@2x 1.png]]
Проверим репу ![[CleanShot 2024-09-14 at 23.40.56@2x.png]]
Добавляем remote

--------------------------------------------------------------------------------
~/gitDterraCrash (main) » git remote add origin https://git.dterra.ru/trainee/gitterrastudy.git

Отправляем изменения в наш GitLab

--------------------------------------------------------------------------------
~/gitDterraCrash (main) » git push --set-upstream origin main

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads

Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 287 bytes | 287.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0), pack-reused 0

To https://git.dterra.ru/trainee/gitterrastudy.git
 * [new branch]      main -> main

branch 'main' set up to track 'origin/main'.
--------------------------------------------------------------------------------

Провереям, что изменения отобразились

![[CleanShot 2024-09-15 at 00.54.44@2x.png]]

Сделаем еще пару изменений, добавим readme.md и файл, который будет в gitignore

--------------------------------------------------------------------------------
~/gitDterraCrash (main) » echo "gitignore" > ingnore.txt
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » echo "ingnore.txt" > .gitignore
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » git add .                   ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » echo "# Intial readme" > readme.md
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » git add .                   ntcad@Mishas-MacBook-Air
--------------------------------------------------------------------------------
~/gitDterraCrash (main*) » git commit -m "ReadMe.md and .gitignore"
[main 3148943] ReadMe.md and .gitignore
 2 files changed, 2 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 readme.md
--------------------------------------------------------------------------------
~/gitDterraCrash (main) » git push origin main         ntcad@Mishas-MacBook-Air

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads

Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 404 bytes | 404.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0

To https://git.dterra.ru/trainee/gitterrastudy.git
   68ef6ec..3148943  main -> main
--------------------------------------------------------------------------------
~/gitDterraCrash (main) »                              ntcad@Mishas-MacBook-Air

Проверим GitLab:

![[CleanShot 2024-09-15 at 00.58.59@2x.png]]

Итог

Все успешно. Мы создали 3 файла и залили только 2, из-за .gitignore

git branch

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

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

Команда git branch позволяет создавать, перечислять, переименовывать и удалять ветки. Однако она не позволяет переключаться между ветками или объединять разветвленную историю. По этой причине git branch тесно интегрирована с командами git checkout и git merge.


git branch

Выводит список всех веток в вашем репозитории. Это то же самое, что и команда git branch --list.


git branch <branch>

Создает новую ветку с именем ＜branch＞. При этом новая ветка не будет автоматически переключена.


git branch -d <branch>

Удаляет указанную ветку. Это "безопасная" операция, так как Git не позволит удалить ветку, если в ней есть несмёрженные изменения.


git branch -D <branch>

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


git branch -m <branch>

Переименовывает текущую ветку в ＜branch＞.


git branch -a

Выводит список всех удаленных веток.

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

![[02 Creating branches (1).svg]]

Затем вы создаете ветку с помощью следующей команды:


git branch crazy-experiment

История репозитория остается неизменной. Вы просто получаете новый указатель на текущий коммит:

![[03 Creating branches.svg]]

[!info] Обратите внимание git branch <name> только создает новую ветку. Чтобы начать добавлять в нее коммиты, нужно переключиться на нее с помощью команды git checkout, а затем использовать стандартные команды git add и git commit.

git checkout

Команда git checkout может работать с тремя различными сущностями: файлами, коммитами и ветками.

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

Команда git checkout тесно связана с командой git branch. Команда git branch используется для создания новой ветки. Когда вы хотите начать новую функцию, вы создаете новую ветку от main с помощью git branch new_branch. После создания можно использовать git checkout new_branch для переключения на эту ветку. Кроме того, команда git checkout поддерживает аргумент -b, который является удобным методом, позволяющим создать новую ветку и сразу же переключиться на нее в отличии от git branch <branch>


git checkout -b <new-branch>

Пример выше одновременно создает и переключается на ветку ＜new-branch＞. Опция -b является флагом, который указывает Git сначала выполнить git branch перед выполнением git checkout ＜new-branch＞.


git checkout -b <new-branch> <existing-branch>

По умолчанию git checkout -b создаст ветку new-branch, основываясь на текущем HEAD. Однако можно передать дополнительный параметр — ветку, на основе которой будет создана новая ветка. В приведенном примере передается ＜existing-branch＞, что означает, что ветка new-branch будет основана на existing-branch, а не на текущем HEAD.

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


git fetch --all

В современных версиях Git после этого вы можете выполнить команду checkout для удаленной ветки так же, как для локальной.


git checkout <remotebranch>

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


git checkout -b <remotebranch> origin/<remotebranch>

Также можно создать новую локальную ветку и сбросить её до последнего коммита удаленной ветки.


git checkout -b <branchname>
git reset --hard origin/<branchname>

git merge

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

![[02 Branch-1 kopiera.png]]

Выполните команду git status, чтобы убедиться, что HEAD указывает на правильную ветку, которая будет принимать слияние. При необходимости выполните команду git checkout, чтобы переключиться на ветку, принимающую слияние. В нашем случае выполните команду:


git checkout main

Убедитесь, что ветка, принимающая слияние, и ветка, из которой производится слияние, обновлены до последних изменений из удаленного репозитория. Выполните команду git fetch, чтобы получить последние удаленные коммиты. После завершения операции fetch убедитесь, что ветка main содержит последние обновления, выполнив команду git pull

После выполнения ранее обсужденных шагов по "подготовке к слиянию" можно инициировать слияние, выполнив команду git merge, где <branch> — это имя ветки, которая будет объединена с принимающей веткой.


git merge <branch>

Это объединит указанный <branch> с текущей веткой, на которую указывает HEAD.

merge conflicts

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

git reset

Команда git reset — это сложный и универсальный инструмент для отмены изменений. У неё есть три основные формы вызова, которые соответствуют аргументам командной строки: --soft, --mixed, --hard. Эти три аргумента соотносятся с тремя внутренними механизмами управления состоянием в Git: Деревом коммитов (HEAD), индексом подготовленных изменений (Staging Index) и рабочей директорией (Working Directory).


git reset ＜file＞

Удаляет указанный файл из области подготовки (staging area), но оставляет рабочую директорию без изменений. Это отменяет подготовку файла, не перезаписывая внесённые изменения.


git reset

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


git reset --hard

Сбрасывает область подготовки и рабочую директорию до состояния последнего коммита. Помимо отмены подготовки изменений, флаг --hard заставляет Git перезаписать все изменения в рабочей директории. Иными словами, это уничтожает все непроиндексированные изменения, поэтому убедитесь, что действительно хотите удалить свои локальные наработки перед использованием этой команды.


git reset ＜commit＞

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


git reset --hard ＜commit＞

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

git fetch

Команда git fetch загружает коммиты, файлы и ссылки из удалённого репозитория в ваш локальный репозиторий. Используют её, когда нужно получить изменения, над которыми работали другие.


git fetch <remote>

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


git fetch <remote> <branch>

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


git fetch --all

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


git fetch --dry-run

Опция --dry-run выполняет демонстрационный запуск команды. Она выводит примеры действий, которые будут выполнены при fetch, но не применяет их.

git pull

Команда git pull используется для получения и загрузки контента из удалённого репозитория с последующим немедленным обновлением локального репозитория в соответствии с этим контентом.

Команда git pull на самом деле представляет собой комбинацию двух других команд: git fetch, за которой следует git merge. На первом этапе выполнения git pull запускает git fetch, ограниченный локальной веткой, на которую указывает HEAD. После загрузки контента git pull переходит к процессу слияния. Будет создан новый коммит слияния, а указатель HEAD обновится, чтобы указывать на этот новый коммит.


git pull <remote>

Загружает копию текущей ветки из указанного удалённого репозитория и сразу сливает её с локальной копией. Это эквивалентно командам git fetch ＜remote＞ и последующему git merge origin/＜current-branch＞.


git pull --no-commit <remote>

Похоже на стандартный вызов команды, загружает удалённый контент, но не создаёт новый коммит слияния.


git pull --rebase <remote>

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


git pull --verbose

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

git diff

Diffing — это функция, которая принимает два набора данных на вход и выводит изменения между ними.

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

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


git diff

Отображает различия между рабочей директорией и индексом. Показывает, что изменилось с последнего добавления изменений в индекс (с использованием команды git add).


git diff --staged

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


git diff <commit>

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


git diff <commit1> <commit2>

Сравнивает различия между двумя коммитами. Это полезно для анализа изменений между двумя конкретными точками в истории проекта.


git diff <branch1> <branch2>

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


git diff --name-only

Отображает только имена файлов, которые изменились, без показа деталей изменений.


git diff --stat

Показывает краткую статистику изменений в каждом файле (количество добавленных и удалённых строк).

git log

Команда git log используется для отображения истории коммитов в репозитории. Она выводит список сделанных коммитов, начиная с последнего, и предоставляет информацию о каждом коммите, такую как идентификатор SHA-1, автора, дату и сообщение коммита.

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


git log

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


git log -p

Показывает полные изменения (diff) для каждого коммита. Это полезно для того, чтобы сразу увидеть, что было изменено в каждом коммите.


git log --stat

Выводит краткую статистику изменений для каждого коммита — количество добавленных и удалённых строк в каждом изменённом файле.


git log --oneline

Отображает каждый коммит в одной строке, показывая сокращённый идентификатор коммита и сообщение коммита. Это удобный способ быстрого просмотра истории коммитов.


git log --graph

Показывает историю коммитов в виде ASCII-графа, представляющего структуру ветвления и слияния. Это наглядно демонстрирует ветки и слияния в репозитории.


git log --author="<name>"

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


git log --since=<date>

Показывает только те коммиты, которые были сделаны после указанной даты. Можно использовать форматы вроде 2.weeks.ago или точные даты (YYYY-MM-DD).


git log --until=<date>

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


git log --grep="<pattern>"

Фильтрует коммиты по шаблону в сообщениях коммитов. Это помогает найти коммиты с определёнными ключевыми словами.


git log --all

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


git log -n <number>

Ограничивает количество выводимых коммитов до указанного числа. Например, git log -n 5 выведет только последние пять коммитов.


git log --name-only

Выводит имена файлов, изменённых в каждом коммите, без детального показа изменений.

Git Crash Course

Суть

Полезные ссылки

Содержание

Основы

Установка git

Что такое репозиторий

Введение и команды GIT

git init

git config

Уровни конфигурации и файлы в Git

Приоритеты уровней

git config, обязательная настройка при установке гита

Области в гите

Рабочая директория

Область индексирования (Staging Area)

Фиксация изменений (Committing Changes)

git add

git commit

git remote

git push

.gitignore

Git ignore patterns

Первая практика

Теперь опубликуем все наши наработки в gitlab

Итог

git branch

git checkout

git merge

merge conflicts

git reset

git fetch

git pull

git diff

git log

ADVANCED

git stash

git tag

git blame

git clean

git revert

git rebase

git reflog

git cherry-pick

git-show