Git в повседневной разработке

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

• Установка и настройка Git: Если у вас ещё не установлен Git, скачайте и установите его с официального сайта git-scm.com. После установки настройте Git, используя свои данные GitHub:

$ git config --global user.name "Ваше Имя" 
$ git config --global user.email "ваша@почта.com"

• Установка GitHub CLI: Установите GitHub CLI с официального сайта cli.github.com.

# для Linux 
$ sudo apt-get update -y && sudo apt-get full-upgrade -y && sudo apt-get autoremove -y && sudo apt-get autoclean -y 
 
$ sudo snap install gh 
# or 
$ sudo apt-get install gh

• Аутентификация в GitHub через CLI: Авторизуйтесь в GitHub через CLI:

$ gh auth login

Следуйте инструкциям в командной строке для аутентификации.

• Инициализация локального репозитория Git: Перейдите в папку с вашим проектом и инициализируйте Git репозиторий:

cd путь/к/вашему/проекту 
git init 
git add . 
git commit -m "Начальный коммит"

• Создание удалённого репозитория на GitHub: Используйте GitHub CLI для создания нового репозитория:

gh repo create имя_репозитория --public --source=.

Выберите --public или --private, в зависимости от того, хотите ли вы, чтобы репозиторий был публичным или приватным. Флаг --source=. свяжет ваш локальный репозиторий с только что созданным удалённым репозиторием.

• Пуш кода в удалённый репозиторий: Наконец, отправьте ваш код в новый репозиторий:

git push -u origin main

Здесь main - это название ветки. Если вы используете другое, замените его соответственно.

Прежде чем начать работу над проектом, клонируйте удаленный репозиторий с помощью команды git clone:

git clone <URL_репозитория>

Здесь <URL_репозитория> - это URL вашего удаленного репозитория.

• Клонирование удаленного репозитория с указанием ветки dev:

git clone -b dev <URL_репозитория>

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

git checkout -b feature-your_task

Замените feature-your_task на название вашей ветки.

Изменяйте код и добавляйте изменения в индекс с помощью git add, а затем делайте коммит с комментарием:

git add . 
git commit -m "Ваши комментарии к коммиту здесь"

Отправьте ваши изменения на удаленный репозиторий в вашу ветку:

git push --set-upstream origin feature-your_task

Проверка статуса вашего репозитория:

git status

Если вам нужно временно спрятать незакоммиченные изменения, воспользуйтесь stash:

git stash

Воспользуйтесь stash, чтобы вернуть ранее спрятанные изменения:

git stash pop

Чтобы отменить все изменения после последнего коммита в Git и вернуть рабочую директорию к состоянию последнего коммита, вы можете использовать команду:

git reset --hard HEAD

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

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

git checkout dev # Переключитесь на нужную ветку 
git pull # Получите изменения из удаленного репозитория 
git checkout feature-your_task # Вернитесь на вашу ветку 
git merge dev # Объедините изменения

Получение и слияние изменений из ветки dev :

git pull --rebase origin dev

Для замены данных в локальной ветке dev данными из удаленной ветки origin/dev, можете выполнить следующие шаги:

# Убедитесь, что вы находитесь в ветке dev: 
git checkout dev 
 
# Сбросьте вашу локальную ветку dev до состояния origin/dev: 
git reset --hard origin/dev 
 
#Получите обновления с удаленного репозитория: 
git pull

Теперь ваша локальная ветка dev будет содержать те же данные, что и удаленная ветка origin/dev.
Убедитесь, что вы понимаете последствия этой операции, так как она перезапишет данные в вашей локальной ветке. Все незакоммиченные изменения будут утеряны.

После завершения задачи, удалите локальную ветку с помощью -d:

git branch -d feature-your_task

Если возникнут проблемы, используйте -D для принудительного удаления:

git branch -D feature-your_task

Удаление ветки с именем <branch_name> на удаленном репозитории:

git push origin --delete <branch_name>

Удаление файла ./db.json из индекса (не из рабочей директории):

git rm --cached ./db.json

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

# Удалите кэшированные файлы индекса: 
git rm -r --cached . 
 
# Добавьте файлы обратно в индекс: 
git add . 
 
#Сделайте коммит: 
git commit -m "Переиндексация .gitignore"

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

git tag -a v1.0.0 -m "Версия 1.0.0"

Просмотреть все созданные теги можно командой:

git tag

Для отправки локальных тегов на удаленный репозиторий используйте:

git push origin --tags

История изменений и коммитов доступна через:

git log

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

Файл .gitattributes позволяет определять настройки атрибутов файлов в репозитории, такие как лингвистические настройки или правила обработки концов строк.

Вот несколько примеров использования файла .gitattributes:

Нормализация концов строк:

Git может автоматически преобразовывать концы строк в CRLF (используется в Windows) при проверке файлов из репозитория и в LF (используется в Linux и macOS) при коммите. Чтобы включить эту функцию для всех текстовых файлов, добавьте следующую строку в .gitattributes:

* text=auto

Если вы хотите, чтобы определенный файл всегда имел концы строк LF, даже в Windows, используйте:

*.sh text eol=lf

Это особенно полезно для скриптов, которые должны выполняться в Linux-окружении.

Определение типа файла:

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

*.myext text

Или чтобы указать, что файлы с расширением .bin должны быть бинарными:

*.bin binary

Игнорирование различий в определенных файлах:

Можно настроить Git так, чтобы он игнорировал изменения в пробелах или вообще любые изменения в определенных файлах при сравнении версий. Например, чтобы игнорировать различия в пробелах для файлов .txt:

*.txt -diff

Или чтобы использовать специальный драйвер diff для файлов определенного типа:

*.custom diff=custom

Здесь custom - это имя драйвера diff, который должен быть определен в конфигурации Git.

Лингвистические настройки:

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

*.gen linguist-generated=true

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

*.example linguist-language=Java

Экспорт архива:

Git позволяет указать, какие файлы или директории должны быть исключены из архивов (например, .zip или .tar файлов), создаваемых командой git archive. Например, чтобы исключить директорию test/ и файл notes.txt из архивов:

test/ export-ignore 
notes.txt export-ignore

Git позволяет добавлять в репозиторий ссылки на другие репозитории как подмодули:

git submodule add <URL_подмодуля>

После клонирования репозитория с подмодулями, их необходимо инициализировать и загрузить:

git submodule init 
git submodule update

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

# Найти хэш коммита 
git log 
a1b2c3d4 
 
# Переключиться на целевую ветку 
git checkout develop 
 
# Применить коммит с помощью черри-пикинга 
git cherry-pick a1b2c3d4

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

git cherry-pick --continue

Если вы решите отменить черри-пикинг, используйте команду:

git cherry-pick --abort