Git для чайников

Лично я использую Git поверхностно. У меня просто нет задач, где нужно сложное ветвление, сложная история изменения и нет командной работы с задачами слияния веток разработки. Поэтому я считаю себя «чайником» в Git, хотя у меня есть свои приёмы работы с Git.

Для чего я использую Git

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

Поэтому сейчас я расскажу именно о локальном использовании Git'а.

Считаем, что вы уже установили Git. На всякий случай уточню, что я работаю под Windows 11.

Инициализация

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

Для этого запускаем командную строку (консоль) через cmd или powershell.

Powershell — это почти тоже самое, только более продвинутая консоль.

Обратите внимание, что в подсказке указывается текущий каталог: например c:\domains\albireo>. В нём, собственно, мы и будем работать.

Инициализация репозитория выполняется командой

git init

После выполнения этой команды будет создан скрытый каталог .git (с точкой). Мне удобно, когда этот каталог виден, поэтому в его свойствах (клик второй кнопкой мыши) я снимаю опцию «скрытый». Так я визуально сразу понимаю, что этот каталог работает с Git.

Сама по себе инициализация просто создаёт рабочий каталог для Git и ничего больше. Если, например, вам больше он не нужен, то можно просто его удалить. Естественно, что при этом потеряется вся история. Но, если скажем, проект стал очень большой и в нём много файлов, то работа Git будет медленной. Поэтому, периодически можно просто сносить каталог Git'a и начинать историю заново.

Проверка статуса

Эта команда, наверное, самая частая:

git status

Она выводит файлы и папки, которые либо изменены, либо требуют фиксации. При первом запуске она покажет всё то, что будет добавлено в репозиторий.

Настройки репозитория

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

Первый файл .git/info/exclude - здесь можно указать какие файлы и папки нужно отслеживать.

Второй файл .git/config - здесь можно указывать разную конфигурацию.

Отслеживаемые папки и файлы

Для этого используем файл .git/info/exclude. Это обычный текстовый файл.

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

Вот пример:

# Игнорировать всё
*

# Разрешить одиночные файлы в корне
!/*

# Разрешить нужные папки в корне
!system/
!templates/
!website/

# Разрешить содержимое этих папок
!system/**
!templates/**
!website/**

# Но игнорировать каталог кэша
website/service/cache/*

# Игнорировать .sqlite везде (даже в разрешённых папках, если надо)
*.sqlite

Если же, стоит задача, наоборот разрешить всё, но запретить избранные, то делается примерно так:

# Игнорировать эти папки
system/
templates/
website/

Тут есть вот какой момент. Для Git'а иногда важно бывает указывать символ «*», который означает «все файлы». Но иногда этот символ не нужен. Поэтому чтобы понимать что именно Git будет добавлять, следует посмотреть через команду

git status

Если там вывод файлов и папок как нужно, то всё ок. Если нет, то нужно редактировать .git/info/exclude.

Первый коммит (фиксация)

После того, как вы определились с папками/файлами, нужно сделать первую фиксацию. Делается это двумя командами. Первая просто добавляет изменения в репозиторий, а вторая фиксирует эти изменения.

Добавляем все изменения:

git add .

Теперь фиксируем:

git commit -m "Init"

Почему add и commit раздельные? 🤔

Всё дело в том, что коммит — это набор многих изменений. То есть через add можно добавлять один файл, потом второй, потом третий, и делать это сколько угодно раз, а потом, скажем в конце работы, их зафиксировать. Поскольку Git — это в первую очередь для командной работы, то такая схема упрощает управление изменением файлов. Для личного использования, конечно же, это несколько избыточно, но мы это решим через псевдонимы (alias).

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

Если же выполнить:

git commit

То Git перейдёт в режим текстового редактора, где нужно будет всё равно указать текст коммита. Причем редактор будет прямо в консоли, и это ужасная жуть. 😨

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

Конфигурация

Откройте файл .git/config. Я покажу сразу свой вариант, у вас будет что-то похожее, кроме секции «alias».

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    autocrlf = false
    editor = notepad
[alias]
    st = status
    hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=format:'%Y-%m-%d %H:%M:%S'
    histp = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=format:'%Y-%m-%d %H:%M:%S' -p
    now = !git add . && git commit -m "auto-commit"
    ghd = !start "" "C:/Users/Administrator/AppData/Local/GitHubDesktop/GitHubDesktop.exe"

Опция ignorecase указывает игнорировать регистр файлов. Это актуально для Windows.

Опция autocrlf указывает на то, как Git будет работать с концами строк. Для Linux это «LF», для Windows «CRLF». Если у вас Windows, то можно просто отключить (false).

Опция editor как раз отвечает за то, какой редактор будет использован по умолчанию. Скажем если выполнить git commit, то Git запустит Блокнот (notepad). И это намного лучше его встроенного редактора.

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

Настройка псевдонимов (alias)

Секция [alias] это то, что здорово упрощает работу с Git.

Алиасы — это команды Git, только в более простой форме. Например вместо git status можно использовать git st, потому что я уже настроил такой алиас.

Команда hist — это лог изменений, а histp — уже подробный лог. В нём можно листать клавишами курсора измененные файлы, а для выхода нажать клавишу q.

Команда now соединяет две команды add и commit. Строго говоря, можно сделать немного проще, но здесь я показываю общий принцип создания алиаса из нескольких git-команд.

И команда ghd запускает GitHub Desktop. Её нужно установить отдельно. Обратите внимание, что путь к программе я указываю полным (у вас он может быть другим), и нужно заменить обратные win-слэши «\» на прямые «/». Программу можно скачать с официального сайта Git.

Алгоритм работы

Кратко обобщим.

• Вначале инициализация.
• Сразу редактируем config, поскольку он будет какой-то свой типовой.
• Потом настраиваем exclude, чтобы указать только то, что нужно отслеживать.
• Потом смотрим git status, чтобы убедиться что настройки верные.
• Делаем первый коммит.

После этого можно вносить изменения в проекте и фиксировать через git now. У всех этих фиксаций будет единая метка auto-commit. Если нужно как-то выделить коммит, то делаем вручную через add и commit.

Если нужна история, то проверяем через git hist. Если нужна детализация, то git histp.

Глобальные настройки

Можно сделать так, чтобы конфигурация стала глобальной. Есть несколько способов, но мне кажется, что самый простой это отредактировать глобальный конфиг-файл. В Windows он будет здесь C:\Users\Пользователь\.gitconfig. В него просто копируем нужные секции и данные из config.

Для проверки, что всё ок, вводим:

git config --global --list

Если так сделать один раз, то можно не править .git/config для каждого репозитория.

Использование Git GUI и GitHub Desktop

Просто наберите команду:

git gui

Запустится отдельная программа Git GUI, которая уже имеет более приятный интерфейс, чем консоль.

Лично я в основном её использую для просмотра истории. Это Repositiry - Visualize main's History. Откроется новое окно, где вверху будут отображены ветка и все коммиты, а внизу их diff-отличия. Это очень напоминает работу с GitHub.

Если вы поставили GitHub Desktop, то эта программа имеет похожий функционал, только ещё и завязана на GitHub. GitHub Desktop можно запускать отдельно, либо через наш алиас

git ghd

Для того, чтобы работать с локальным репозиторием, нужно его добавить вручную File - Add local repository. После подключения будет две вкладки «Changes» и «History», где можно видеть изменения по коммитам.

Как сделать отмену

Например у вас есть файл, в котором когда-то были изменения. Эти изменения вы внесли в таком-то коммите. И вам нужно отменить эти изменения.

Для этого используется команда checkout. В общем виде она выполняется так:

git checkout a1b2c3d -- путь/к/file.txt

Строка a1b2c3d — это хэш коммита откуда нужно вернуть файл. Как его найти?

Самый простой вариант, это использовать git gui и по истории посмотреть какой это был коммит и скопировать его хэш. Он в полном виде будет примерно такой «54ff5a6d7febadc6ecef7387eae0b86c16c1845e». Имя файла копируется там же.

После того, как выполнен «checkout» нужно зафиксировать изменения, например так:

git commit -m "Вернул путь/к/file.txt"

История изменений по файлу

Иногда нужно посмотреть изменения только по одному файлу.

git log -- путь/к/file.txt

Если изменений много, то их можно пролистать пробелом, а для выхода нажать клавишу q.

Работа с тэгами

Тэги (tags) — это простой способ создавать некие «фиксированные» версии или релизы. Ну например вы внесли все изменения и хотите зафиксировать статус проекта. В этом случае можно создать тэг, где указать номер версии.

В простом виде это делается так:

git tag v.2025.06.20

где v.2025.06.20 — это и есть номер версии. Текст может быть произвольным.

Либо можно сделать аннотацию:

git tag -a v.2025.06.20 -m "Релиз версии 2025.06.20"

Посмотреть все версии можно так:

git tag

Если вы работаете в Git GUI, то в истории есть пункт меню List references, где и выводятся все эти тэги.

В случае, если тэг нужно удалить:

git tag -d v.2025.06.20

Сами по себе тэги никак не сказываются на коммитах. Это просто удобный способ навигации.

«Распухший» репозиторий

С этим я часто сталкиваюсь, поскольку по умолчанию Git хранит объёмные файлы, например изображения. Тут у меня нет особых рецептов, кроме того, что я принципиально решаю нужно ли мне отслеживание таких файлов.

Здесь можно подойти двояко.

В первом случае можно просто запретить в файле .git/info/exclude отслеживание jpg/webp/png/pdf-файлов, то есть тех, что потенциально могут быть объемными. Для этого просто добавляем:

*.webp
*.jpg
*.png
*.pdf

Другой способ это выборочно игнорировать каталоги с такими файлами:

uploads/*.webp
uploads/*.jpg
uploads/*.png
uploads/*.pdf

Для того, чтобы проверить насколько репозиторий «распух» можно в Git GUI выбрать Repository - Database Statistics и посмотреть сколько он занимает места. И там же есть кнопка для сжатия.

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

Архивирование веток

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

Например вы сделали несколько тэгов, скажем v1, v2 и есть текущий вариант без метки. И вам нужно получить архив каждой версии.

Для создания архива я использую небольшую python-программу, которую мне быстро накидал Deepseek. Привожу полный код (run_versions.py).

import os
import zipfile
from datetime import datetime

# ===== НАСТРОЙКИ ===== #
ARCHIVE_DIR = "_versions"    # Папка для хранения архивов
DIRS_TO_ADD = ["system", "templates", "website"]  # Каталоги для добавления
# ===================== #

def create_zip_archive(source_path, archive_name):
    with zipfile.ZipFile(archive_name, 'w') as archive:
        for file in os.listdir(source_path):
            file_path = os.path.join(source_path, file)
            if os.path.isfile(file_path):
                archive.write(file_path, arcname=file)
        
        for dir_name in DIRS_TO_ADD:
            dir_path = os.path.join(source_path, dir_name)
            if os.path.isdir(dir_path):
                for root, dirs, files in os.walk(dir_path):
                    if ARCHIVE_DIR in dirs:
                        dirs.remove(ARCHIVE_DIR)
                    for file in files:
                        file_path = os.path.join(root, file)
                        arcname = os.path.relpath(file_path, start=source_path)
                        archive.write(file_path, arcname=arcname)

def main():
    current_dir = os.getcwd()
    archive_dir_path = os.path.join(current_dir, ARCHIVE_DIR)
    
    if not os.path.exists(archive_dir_path):
        os.makedirs(archive_dir_path)
    
    timestamp = datetime.now().strftime("%Y-%m-%d_%H-%M-%S")
    archive_name = os.path.join(archive_dir_path, f"backup_{timestamp}.zip")
    
    create_zip_archive(current_dir, archive_name)
    print(f"[+] Архив создан: {archive_name}")

if __name__ == "__main__":
    main()

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

Дальше так. Например мы хотим сделать архив версии «v1». Вначале переключаемся на неё:

git checkout v1

Эта команда вернет файлы к этой версии. Теперь выполняем скрипт run_versions.py, который создаст zip-архив.

Не забудьте добавить в .git/info/exclude каталог _versions!

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

git checkout main

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

Бонус. Настройка Notepad++

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

В Notepad++ есть одна замечательная фишка — резервное копирование при сохранении. Нужно выбрать Опции - Настройки - Резерв. копирование и там отметить опцию Копирование при сохранении, Подробное (дата и время) и указать каталог, например c:\temp\bak.

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