Система контроля версий Git

Привет всем подвальным дефолдерам и не только :smiling_face_with_sunglasses:

В этой теме мы будем учиться работать с Git!
В этом посте мы установим Git на Windows и научимся запускать Git Bash.

Знакомство с Git

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

Зачем нужна система контроля версий?

  • Сохранение промежуточных версий проекта(истории изменений).
  • Возможность командной работы над одним проектом.
Работа с Git в командной строке

На macOS и Linux используйте стандартный терминал, в котором также можно работать с Git.
На Windows нужно использовать программу Git Bash. Именно она позволяет использовать команды Git в среде Windows.

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

Установка Git в Windows

У меня Windows 10, но установка Git на Windows 11 в целом аналогичная.

Переходим на официальный сайт Git: https://git-scm.com/
Переходим в раздел “Download”:


Скачиваем последнюю версию:

Начинается загрузка файла в браузере:

Открываем загруженный файл:

Принимаем лицензионное соглашение (нажимаем “Next”):

Выбираем место, куда будет установлены файлы Git (оставим по умолчанию):

Появилось окно с опциями:

Добавить иконку на рабочий фон:
image
Добавить в контекстное меню выбор “открыть с помощью Git Bash” и “открыть с помощью Git GUI”:
image
Что имеют в виду:

Добавляет в Git плагин для работы с файлами большого размера:
image
Ассоциировать Git-конфигурации со стандартным текстовым редактором:
image
Запускать скриптовые файлы с помощью Git Bash:
image
Ежедневно проверять обновления git:
image
Добавляет профиль Git Bash в Windows Terminal для удобного доступа через интерфейс терминала:
image
Плагин для управления большими репозиториями, облегчающий работу с масштабными проектами:
image
Я выбрал такие опции:

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

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

Предлагают выбрать название ветки при создании нового репозитория после “git init”:
Первый пункт предлагает создавать репозитории с именем “master”.
Второй пункт позволяет установить своё значение имени главное ветки.

Выберем второй пункт, которйы позволит добавить к переменной окружения PATH путь до Git, с выбором этого пункта мы сможем запускать git из консоли или пользоваться в средах разработки без проблем:

Выберем 1 пункт:

Выберем 2 пункт:

Выберем 1 пункт:

Выберем 1 пункт:

Выберем 1 пункт:

Выберем 1 пункт:

Выберем 1 пункт:

Запустим Git, поставив галочку как на скриншоте:

Проверим версию Git с помощью команды git --version:

Запуск Git Bash в ОС Windows

Есть два универсальных способа запустить Git Bash на вашем компьютере.

Способ 1. Через Git Bash Here

Этот способ сработает, если при установке Git была выбрана опция Git Bash Here:


Теперь, после установки Git, у вас появилась возможность открывать Git Bash, нажав правой кнопкой мыши на папку, в которой вы планируете работать над проектом, и выбрав пункт меню Git Bash Here:

Выбрав этот пункт, Git Bash откроется в нужной папке, и вы сможете сразу приступить к работе с Git:

Способ 2. Добавить Git в окружение

Вы можете добавить Git в переменные окружения, чтобы удобнее было открывать его не через интерфейс ОС Windows. Для этого:

  1. Нажмите сочетание клавиш Win + R → впишите в появившемся окне cmd → нажмите сочетание Ctrl + Shift + Enter.
  2. В открывшуюся консоль вставьте команду setx Path "полный_путь_к_папке_с_Git" /M и нажмите Enter. По умолчанию Git устанавливается в %ProgramFiles%\Git, поэтому полная версия команды будет выглядеть так: setx Path "%Path%;%ProgramFiles%\Git" /M.

    Теперь вы можете вызвать Git Bash следующим образом: нажать сочетания клавиш Win + R → вписать в появившемся окне git-bashнажать Enter.
    Обратите внимание : по умолчанию таким способом Git Bash будет открываться в домашней директории пользователя. Следовательно, перед непосредственной работой с Git нужно перейти к целевой директории, указав команду $ cd <путь_к_папке>. В примере на скриншоте ниже указана команда для перехода к «папке», которая расположена на рабочем столе:

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

2 лайка

Работа с Git в командной строке

Минимальная настройка Git, первый коммит и др.

Создадим новый проект:


Откроем проект в проводнике Windows:

Откроем Git-Bash в корневой папке проекта:


Проверить содержимое этой папки можем с помощью команды ls -la:

Давайте убедимся, что в ней нет git-репозитория, для этого выполним команду git status:
image
Git-репозитория нет.

Создадим git-репозиторий с помощью команды git init:
image
Инициализировался пустой репозиторий.

.git — это особая папка, в которой хранится вся информация изменений в текущем репозитории
Вновь напишем команду ls -la:


Появилась папка .git.

Введём команду git status:


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

Добавим их в наш репозиторий с помощью команды git add . и git commit -m 'initial'
image
Пробуем создать коммит:


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

git config --global user.name "Your Name"
git config --global user.email "your@example.com"

Для копирования выделите текст:
image
Нажмите ПКМ по полю ввода и выберите “Paste”:

Введём вышестоящие команды последовательно:
image
image
Чтобы узнать какая почта введена:
image
Чтобы узнать какое имя введена:
image

Снова попробуем “закомитить” изменения:


Убедимся, что изменения действительно сохранились в репозитории:

Нажимая на Enter, мы можем просмотреть на все файлы в совершенного коммита.
Здесь мы можем увидеть информацию об авторе коммита — d_bl1n. Его почтовый адрес — programmer@defolder.com.
Дату коммита: Sat Jul 5 17:31:55 2025 +0700
Комментарий к коммиту: initial
Также отображается хэш-коммита: b00eda0e7d01f6b188ef5b7fbe304baea21814b8, по которому мы потом можем обращаться к этому коммиту.
Чтобы выйти из режима просмотра, нажмите q.

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


Например, добавим в main.collection игровой объект.
Сохраним проект с помощью комбинации клавиш: ctrl + C.
Введём команду git status в git bash:

Как видим из скриншота, изменения затронули файл main.collection.
Добавим измененный файл в репозиторий:
image
Сохраним изменения:
image
С помощью команды git log посмотрим всю историю изменений репозитория:

Репозиторий — это папка, в которой система контроля версий Git позволяет отслеживать все изменения, как в структуре файлов и папок, так и в их содержимом.

Команды, затронутые в этом уроке:

  • git init — Инициализирует новый Git репозиторий в текущей директории. Создаёт скрытую папку .git, где хранится вся информация о репозитории.

  • git status — Показывает состояние рабочей директории и индекса. Отображает, какие файлы были изменены, добавлены или удалены по сравнению с последним коммитом, и отслеживает ли Git эти изменения.

  • git add — Добавляет изменения в индекс (staging area). Используется для выбора изменений, которые вы хотите включить в следующий коммит. Можно добавить конкретный файл или все изменения с помощью git add .

  • git commit — Фиксирует изменения из индекса в репозиторий. Создаёт новый коммит с сообщением, описывающим изменения. Пример: git commit -m "Description of changes".

  • git show — Показывает информацию о последнем коммите или о конкретном коммите, включая изменённые файлы, добавленные или удалённые строки. Может использоваться для просмотра содержимого коммитов.

  • git log — Отображает список коммитов в репозитории в хронологическом порядке, начиная с последнего. Показывает хеш коммита, автора, дату и сообщение коммита. Удобно для просмотра истории изменений.

  • git config --global user.name "Your Name" - Эта команда устанавливает ваше имя пользователя глобально для Git. Это значит, что любой новый коммит, который вы будете делать в любом репозитории на вашем компьютере, будет подписан этим именем. “Your Name” нужно заменить на ваше реальное имя.

  • git config --global user.email "your@example.com" - Эта команда устанавливает ваш email адрес глобально для Git. Аналогично команде выше, она подписывает ваши коммиты этим email’ом. Замените “your@example.com” на ваш реальный email.

Флаг --global указывает, что настройки будут применены глобально для всех ваших репозиториев на этом компьютере. Без этого флага изменения будут применены только к текущему репозиторию.

1 лайк

Жизненный цикл файлов в репозитории

Жизненный цикл файлов в Git часто упрощённо описывают как три основных состояния, связанных с процессом работы в репозитории.
Это:
1. Неотслеживаемый/Изменённый (Untracked/Modified):

  • Файл создан или изменён в рабочей директории (working directory), но Git ещё не знает о нём (untracked) или заметил изменения (modified).
  • Состояние: файл виден в git status как “untracked” или “changes not staged”.

2. Добавлен в индекс (Staged):

  • После команды git add <файл> файл попадает в staging area (индекс).
  • Теперь изменения готовы к коммиту, но ещё не сохранены в истории репозитория.
  • Состояние: файл отображается в git status как “changes to be committed”.

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

3. Закоммичен (Committed):

  • После git commit изменения из индекса фиксируются в локальном репозитории как новый коммит.
  • Файл теперь часть истории репозитория, хранится в .git/objects с уникальным хэшом.
  • Состояние: файл “чистый” (нет изменений в git status).

Почему три состояния?
Эти три состояния отражают основной цикл работы с файлами в Git: изменение → подготовка → фиксация. Однако в реальной практике есть дополнительные этапы (например, синхронизация с удалённым репозиторием через git push/pull, ветвление, откат изменений), которые я описал ранее, но они выходят за рамки базового цикла.

Пример:

  1. Создал file.txt → он untracked.
  2. git add file.txt → файл staged.
  3. git commit -m "Добавить file.txt" → файл committed.

Откроем проект, с предыдущего поста и добавим какой-нибудь в этот проект файл:


Добавим созданный компонент к игровому объекту(созданному в прошлом посте) в main.collection.
image
Удалим файл README.md:

Сохраним проект комбинацией клавиш ctrl + S.
Откроем Git-Bash в этом проекте как в прошлом посте:



Введём команду git status:

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

Нужно отметить, что в IDE Defold, в правой нижней панели, отображаются изменения файлов репозитория:

Из этих 3 изменений добавим 2 в индекс:

Сделаем коммит:
image
Убедимся, что изменения произошли (git status):


Убедимся, что изменения попали в коммит (git show):

Ещё раз напомню, что при использовании команды git status мы можем увидеть состояние untracked:
image
Так отображаются новые файлы, добавленные в репозиторий. Это те файлы, изменения которых пока не отслеживаются системой контроля версией Git. Если мы их добавим в индекс, изменения начнут отслеживаться.

Повторим команды:

  • git status — показывает состояние рабочей директории и индекса: какие файлы изменены, добавлены или готовы к коммиту.
  • git add <file(s)> — добавляет указанные файлы в индекс (staging area) для следующего коммита.
  • git commit -m 'comment' — создаёт коммит с изменениями из индекса, добавляя комментарий.
  • git show — отображает подробную информацию о последнем коммите (или указанном), включая изменения.
2 лайка

Игнорирование изменений

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

Какие файлы не следует сохранять в репозитории?

  1. Логи:

    • *.log, logs/, error.log, debug.log
    • Причина: логи содержат временную отладочную информацию, которая не нужна в репозитории.
  2. Пользовательские файлы:

    • user.settings, *.prefs, local.properties
    • Причина: эти файлы специфичны для пользователя и не должны быть общими.
  3. Файлы сред разработки:

    • .idea/ (IntelliJ), .vscode/, *.sublime-project
    • Причина: настройки IDE индивидуальны и не относятся к проекту.
  4. Внешние библиотеки:

    • node_modules/, vendor/, lib/ (если загружаются автоматически)
    • Причина: библиотеки обычно устанавливаются через менеджеры зависимостей.
  5. Файлы локальной конфигурации:

    • .env, config.local.yml, *.conf
    • Причина: содержат чувствительные данные (пароли, ключи API) или локальные настройки.
  6. Файлы операционной системы:

    • .DS_Store (macOS), Thumbs.db (Windows), desktop.ini
    • Причина: это системные файлы, не связанные с кодом.
  7. Слишком большие файлы, не содержащие код:

    • *.zip, *.exe, *.mp4, *.jpg (если не часть проекта)
    • Причина: такие файлы увеличивают размер репозитория, их лучше хранить в облаке или LFS.

Файл .gitignore создаётся как обычный текстовый файл, только имеет название .gitignore. При создании проекта на Defold, файл .gitignore создаётся автоматически.
Его содержимое по умолчанию:

/.editor_settings
/.internal
/build
.externalToolBuilders
.DS_Store
Thumbs.db
.lock-wscript
*.pyc
.project
.cproject
builtins

Давайте в нашем проекте создадим файл errors.log:

Введем любое содержимое и сохраним:

Введём команду git status:


У нас появился один не отслеживаемый файл.
Если бы Defold не создал бы файл .gitignore автоматически, то вам пришлось бы создать его самому.

Лог файлы добавлять в репозиторий не нужно, поэтому мы добавим error.log в .gitignore.

Теперь файл error.log не отображается:

Теперь создадим ещё один лог-файл:


А в .gitignore добавим маску *.log:
Два файла с расширением .log не отображаются:

Если уберем *.log, то они снова появятся в списке untracked:

Теперь попробуем отключить отслеживание целой папки. Создадим папку logs со всеми логами(переместим туда оба наших файлов с расширением .logs).
Проверим git status:


Добавим в исключение папку logs:


/” в конце говорит, что это папка, а не файл.

Можно также намерено указать, что конкретный файл в этой папке не нужно исключать.
Создадим еще один файл в папке logs:


Добавим строки в .gitignore:

! говорит, что этот файл не нужно исключать.

Теперь, если мы добавим в индекс файлы, то через git status сможем увидеть добавленные файлы:

Добавился только один файл из папки logs, который мы исключили из правила logs/*.log с помощью “!”.

Примечание: нельзя исключить отдельный файл из исключенной целиком папки.

Если бы мы ввели:

logs/ 
!logs/keys.log

то ничего бы не вышло.

Подытожим
В .gitignore мы можем указывать:

  • отдельные файлы
  • наборы файлов, используя * как маску
  • папки
  • группы файлов в папках
  • исключать файлы или папки из тех правил, которые были написаны выше.
1 лайк

Удалённые и локальные репозитории

Репозиторий — это папка, в которой система контроля версий Git позволяет отслеживать все изменения, как в структуре папок и файлов, так и в их содержимом.

Локальный репозиторий — это копия проекта, хранящаяся на вашем компьютере, где вы работаете с файлами, вносите изменения и фиксируете их через Git-команды (например, git commit). Создаётся путём клонирования (git clone) или инициализации (git init).

Удалённый репозиторий — это версия проекта, размещённая на сервере (например, GitHub, GitLab). Он служит центральным хранилищем, где команда синхронизирует изменения. Вы обмениваетесь данными с ним через git push (отправка изменений) и git pull (загрузка изменений).

Для командной работы используется удалённый (центральный) репозиторий, размещённый на сервере. Локальные репозитории, находящиеся на компьютерах разработчиков, создаются путём клонирования центрального репозитория.

Чтобы начать работу над проектом, вы клонируете удалённый репозиторий на свой компьютер с помощью команды git clone. Полученный локальный репозиторий (рабочая копия) используется для внесения изменений, которые фиксируются через коммиты. Изменения отправляются на сервер командой git push.

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

1 лайк

Работать с Git-репозиториями можно по разному, можно в командной строке, с которой мы уже знакомы. Можно в среде разработки. А можно в специальной системе.

Зачем нужны системы управления репозиториями?

  1. Визуальное представление.
  2. Управление доступами.
  3. Таск-трекер.
  4. Связь изменений с задачами.

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

  1. GitHub
  2. GitLab

GitHub и GitLab — это платформы для хостинга удалённых Git-репозиториев, но у них есть различия:

GitHub:

  • Популярная платформа, ориентированная на open-source проекты.
  • Простой интерфейс, удобный для начинающих.
  • Бесплатный тариф: публичные репозитории, ограниченные приватные (до 3 коллабораторов).
  • Интеграции: CI/CD (GitHub Actions), сторонние сервисы.
  • Принадлежит Microsoft, больше ориентирован на сообщество и сторонние интеграции.
  • Ограниченные возможности для самохостинга (нужен GitHub Enterprise).

GitLab:

  • Более функциональная платформа, подходит для DevOps.
  • Бесплатный тариф: публичные и приватные репозитории без ограничений на коллабораторов.
  • Встроенные инструменты: CI/CD, контейнеры, мониторинг, управление проектами.
  • Возможность самохостинга (установка на своём сервере).
  • Открытый исходный код (open-source), гибкость настройки.
  • Более сложный интерфейс, но больше возможностей для крупных команд.

Ключевые различия:

  • Функционал: GitLab предлагает больше встроенных DevOps-инструментов, GitHub проще и больше заточен под сообщество.
  • Хостинг: GitLab поддерживает самохостинг, GitHub — преимущественно облачный.
  • Цена: GitLab щедрее на бесплатные функции для приватных проектов.
  • Интерфейс: GitHub интуитивнее, GitLab мощнее, но сложнее.

Выбор зависит от потребностей: для простоты и open-source — GitHub, для DevOps и самохостинга — GitLab.

2 лайка

Создание удалённого репозитория на GitHub

Чтобы приступить к созданию удаленного репозитория на GitHub, необходимо пройти процесс регистрации.
Переходим на GitHub: https://github.com/
image
Вводим свою почту, пароль, имя пользователя, выбираем страну:


После того, как вы завершите процесс регистрации, перейдите:



Рассмотрим каждый пункт:

  1. Выберите владельца и задайте имя репозитория

    • Владельцем может быть ваш аккаунт или организация.
    • Имя репозитория должно быть уникальным, кратким и отражать суть проекта.
  2. Добавьте описание репозитория

    • Кратко опишите цель и назначение проекта (необязательно, но полезно для других пользователей).
  3. Настройте уровень доступа

    • Публичный: любой пользователь может просматривать содержимое.
    • Приватный: доступ только у приглашённых коллабораторов.
  4. Добавьте файл README

    • Создайте файл README.md для описания проекта, инструкций и информации для пользователей.
    • Рекомендуется включить, так как это главная страница проекта.
  5. Добавьте шаблон .gitignore

    • Выберите готовый шаблон .gitignore для исключения ненужных файлов (например, для Python, Node.js).
    • Это предотвращает загрузку временных или системных файлов в репозиторий.
  6. Выберите лицензию

    • Укажите лицензию (например, MIT, Apache 2.0), чтобы определить правила использования кода.
    • Без лицензии проект по умолчанию считается закрытым для использования другими.

Примечание: На странице создания репозитория GitHub также предлагает инициализировать репозиторий с начальным коммитом (README, .gitignore, лицензия), что упрощает старт работы.

Нажмите на зеленую кнопку: “Create Repository”. После чего GitHub сразу предложит варианты работы с репозиторием:

2 лайка

Способы подключение к удаленному репозиторию

Варианты подключения

Когда нет ни локального репозитория, ни удаленного репозитория:

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

  • Первый вариант. Создать в репозитории хотя бы один файл. Это можно сделать, нажав на ссылку: “создать файл”. Дальше нужно будет создать коммит.
  • Второй вариант. Загрузить в этот репозиторий какой-нибудь файл.

    Дальше нужно будет создать коммит.
    Или, можно попробовать создать репозиторий таким образом:

    Создадим папку, назовём её также, как называется наш репозиторий:

    Создадим в этой папке какой-нибудь файл.
    Можно с помощью командной строки:
    image
    Можно с помощью проводника:
    image
    После создания файла, выполним команду git init:
    image
    Добавим этот файл в индекс:
    image
    Сделаем коммит:

    Теперь подключим наш репозиторий к удалённому:

    image
    Далее выполним эту команду, отправив все локальные изменения в удалённый репозиторий:
    git push -u origin main
    У вас откроется окно:

    Войдём с помощью браузера:

    Всё прошло успешно:


    С помощью команды git remote -v можно просмотреть путь к настроенному репозиторию:
    image
    Также можно удалить путь к удалённому репозиторию с помощью команды git remote remove origin
    Добавить путь к удалённому репозиторию с помощью команды git remote add origin (путь к нему)
Когда есть локальный репозиторий, но удалённого репозитория ещё нет:

Имеется репозиторий с одним файлом:
image
Первым действием нужно создать удалённый репозиторий:


Откроем Git Bush в папке с репозиторием и выполним инструкции:

Подключаемся к удалённому репозиторию:
image
Отправим изменения на удалённый репозиторий:

Проверим репозиторий на GitHub:

Когда нет локального репозитория, но есть удалённый репозиторий:

Имеется удалённый репозиторий:


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

Теперь в командной строке склонируем путь к git-репозиторию:

Появилась папка рабочего репозиторий:

Основные команды:

  • git init
    Инициализирует новый Git-репозиторий в текущей папке. Создаёт скрытую директорию .git, где хранятся все данные для контроля версий.

  • git remote add origin path
    Добавляет удалённый репозиторий с именем origin и указанным путём (path, например, URL репозитория на GitHub). Это связывает локальный репозиторий с удалённым.

  • git push -u origin master
    Отправляет локальные коммиты из ветки master в удалённый репозиторий origin. Флаг -u (или --set-upstream) устанавливает связь между локальной веткой master и соответствующей веткой в удалённом репозитории, чтобы в будущем можно было использовать просто git push.

  • git remote -v
    Показывает список всех удалённых репозиториев, связанных с вашим проектом, вместе с их URL. Флаг -v (verbose) выводит подробную информацию (имя репозитория и адреса для push/fetch).

  • git remote remove origin
    Удаляет связь с удалённым репозиторием с именем origin. После этого локальный репозиторий теряет привязку к указанному удалённому репозиторию, но локальные данные остаются нетронутыми.

1 лайк

Внесение изменений и их отправка

Давайте зайдём в проект, в котором находится репозиторий и добавим какое-нибудь изменение в файл.

Например, в файле contoller.script:

function init(self)
	msg.post("", "acquire_input_focus")
end

Посмотрим изменения в командной строке с помощью команды git status:


Мы видим, что произошли изменения в файле contoller.script — он подсветился красным цветом.
Добавим этот файл в индекс:

Создаём новый коммит:
image
Посмотрим изменения локального репозитория с помощью git status:


Мы видим, что в ветке ‘origin/main’ есть 1 коммит, этот коммит находится только в рабочем репозитории.
Коммита с комментарием “second commit” на удалённом репозитории ещё нет:


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

Просмотрим историю коммитов:


Поскольку в первый раз, когда мы подключались к удалённому репозиторию, используя git push -u, теперь мы можем выполнять git push без параметров.
Параметр -u, автоматически устанавливает связь между локальным и удалённым репозиторием таким образом, чтобы далее можно было использовать просто команду git push.
Мы можем просмотреть любой коммит и изменения в нём:

Основные команды:

  • git status: Показывает текущую ветку, изменённые файлы и их статус (не в индексе, в индексе, готовы к коммиту).
  • git add .: Добавляет все изменённые файлы в текущей директории в индекс для коммита.
  • git commit -m 'message': Создаёт коммит из файлов в индексе с указанным сообщением.
  • git push: Отправляет локальные коммиты в удалённый репозиторий (в текущую ветку).

Обновление локального репозитория

Откроем локальный репозиторий предыдущего проекта и воспользуемся командой git pull:
image
Мы видим, что изменений на сервере пока нет, в нашем репозитории самая свежая версия кода проекта. Но ситуации могут быть разные…

Версии кода в репозиториях:

Локальная версия = удалённая версия:

Версия кода в локальном и удалённом репозитории одинаковые. Все коммиты на вашем компьютере и сервере одни и те же.

Локальная версия > удаленная версия:

Вы внесли изменения, но не отправили их на сервер.
Внесём изменения в файле локального репозитория:


Сделаем git add . и git commit -m 'just commit':

Введём команду git status:

Теперь у нас есть коммит, который старше версии, полученный с сервера. Версия локального репозитория обгоняет версию проекта с сервера на один коммит.
Сделаем git pull, версия локального репозитория равна версии кода проекта с сервера:
image

Локальная версия < удалённая версия:

Отправим предыдущие изменения на сервер с помощью команды git push:


Если выполним команду git status, то увидим, что коммитов со стороны локального репозитория нет.
image
Если выполним команду git pull, то увидим, что версии кода одинаковы:
image
Сделаем так, чтобы версия на удаленном репозитории оказалась выше:

Добавим файл:

Создадим коммит:

Команда git status не покажет изменения:

Но если мы выполним команду git pull, то затянем изменения с сервера:

Конфликт версий

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

1 лайк

Разрешение конфликтов при обновлении репозитория

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

Простой конфликт версий:

Внесём в локальном репозитории изменения в каком-нибудь файле(добавил точку):
image
Сохраним изменения в файле и сделаем коммит:
image
А в удаленном репозитории удалим другой файл:
image


Добавим коммит:
image
Если выполним команду git status, то мы не узнаем, есть ли изменения на удаленном сервере:

Пробуем выполнить команду git push:

Эти подсказки говорят о том, что у нас конфликт версий и нам нужно выполнять сначала команду git pull:

Откроется текстовый редактор(в зависимости от указанных настроек при установке git):

Git сделал слияние между файлами. Текст в текстовом редакторе, это сообщение к текстовому коммиту, вы его можете изменить:

Его можно закрыть, нажав в консоли q:

Теперь отправим изменения на сервер:

Сложный конфликт версий:

Изменил код в файле на локальном репозитории:
image
Добавим файл в индекс и сделаем коммит:
Теперь в удаленном репозитории, в этой же строке кода сделаем изменение:


Сделаем коммит:

Теперь сделаем git pull:

Выдаёт сообщение о конфликте изменений при слиянии.
Если мы выполним команду git status, то увидим, что git сделал слияние файла, но нужно отредактировать его.

В редакторе Defold появились изменения в коде:


Удалим служебные строки, оставим пустую строку (область во втором прямоугольнике):
image
Теперь снова сделаем коммит:
image
Отправим этот коммит на сервер:

Создание веток и работа с ними

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

При вводе команды git status выводится название ветки:
image

Чтобы создать новую ветку введём команду git checkout -b camera:
Параметр b указывает на то, что ветка новая и её нужно создать
camera — название ветки, мы будем реализовывать в этой ветке камеру
image
Switched означает, что репозиторий переключился на новую ветки camera.
Теперь в этой ветке мы можем внести изменения в код и сделать коммит.
Создадим файл или внесём изменения в коде:
image
Проверим состояние репозитория:


Мы видим, что мы находимся в ветке camera.
Добавим изменения в индекс и сделаем коммит:

Посмотрим состояние репозитория и историю коммитов:

Мы видим коммит из ветки camera.
Если переключимся на ветку origin, то мы не увидим ветку camera:
image

Создадим теперь другую новую ветку cursor. Если мы создадим её сейчас, то она будет создана на основе текущей версии ветки. Создавать мы будем на основе той же версии из ветки main, как и ветка camera:
image
Создадим изменения в ветке:
image
Убедимся, что мы находимся в нужной ветке:

Добавим файл в индекс и сделаем коммит:

Введём команду git log:

Сейчас мы находимся в ветке cursor:

image
Переключимся на ветку main:
image

Мы видим изменения структуры файлов в редакторе Defold.

Основные команды:

  1. git status
    Показывает состояние рабочей директории и индекса: какие файлы изменены, добавлены в индекс или готовы к коммиту.
  2. git add .
    Добавляет все изменённые файлы в текущей директории (и поддиректориях) в индекс для следующего коммита.
  3. git commit -m ' '
    Создаёт коммит с изменениями из индекса, добавляя сообщение (в кавычках указывается описание коммита, например, 'Add new feature').
  4. git log
    Отображает историю коммитов в текущей ветке (хэш, автор, дата, сообщение).
  5. git checkout -b new-branch
    Создаёт новую ветку с именем new-branch и сразу переключается на неё.
  6. git checkout main
    Переключается на ветку main (или другую указанную ветку).
  7. git branch
    Показывает список всех веток в репозитории, выделяя текущую ветку звёздочкой
1 лайк

Работа с удалёнными ветками

В локальном репозитории есть ветка, на удалённом репозитории её нет:

В предыдущем посте мы создавали новую ветку в локальном репозитории, сделаем коммит и попробуем отправить какую-нибудь ветку на сервер:



Произошла фатальная ошибка. Предлагается создать ветку в удалённом репозитории:

На сервере теперь отображаются две ветки:
image
Внесём любые изменения в этой же ветке:



В локальном репозитории нет ветки, на удалённом есть:

Создадим ветку control на удалённом репозитории:
image



Просмотрим, какие ветки имеются в локальном репозитории:
image
Звёздочка и зеленый цвет означает, нашу текущую ветку, в которой находится сейчас репозиторий.
Получим ветки с удалённого репозитория:



Обратите внимание, что после ХЭША коммита указаны ветки, в которых этот коммит есть.

В локальном репозитории есть ветка и в удалённом репозитории есть ветка:

Внесём изменения в ветке control:


Создал файл.
Добавим файл в индекс и сделаем коммит:

Отправим изменения на сервер:


Теперь сделаем наоборот:
Перейдём в ветку control:

Нажмём на карандаш, чтобы редактировать файл:



Затянем изменения в локальный репозиторий:



Просмотреть все ветки можно с помощью git branch -a:

Красным цветом выделяются удаленные ветки, локальные серым и зеленым. Зеленым цветом выделяется текущая ветка.

Список команд:
  1. git push -u origin branch-name
    Отправляет локальную ветку branch-name в удалённый репозиторий (origin) и устанавливает связь между локальной и удалённой веткой для упрощения последующих git push/pull.

  2. git pull
    Загружает изменения из удалённого репозитория и объединяет их с текущей локальной веткой. Обычно это комбинация git fetch и git merge.

  3. git checkout branch-name
    Переключает рабочую директорию на указанную ветку branch-name, обновляя файлы до состояния этой ветки.

  4. git branch
    Показывает список локальных веток, текущая ветка отмечена звёздочкой (*).

  5. git push
    Отправляет изменения из текущей локальной ветки в связанную удалённую ветку (если она настроена).

  6. git branch -a
    Показывает список всех веток: локальных и удалённых (с префиксом remotes/origin/).

Откладывание изменений

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


Чтобы отложить изменения с возможностью перейти на другую ветку нужно ввести git stash:
image
В редакторе код был изменён:

Если мы введём команду git status:
image
Мы увидим, что изменений нет, хотя, в прошлый раз они были.
Теперь снова можем совершить изменени. Например, удалим этот блок кода:

Добавим файл в индекс и сделаем коммит:

Теперь вернёмся к отложенным изменениям с помощью команды git stash pop:

Обратим внимание, что удалённый блок кода отсутствует:

По сути, произошло слияние версии кода из коммита c изменениями, вытащенными из отложенного изменения. Вытащенные изменения мы также можем закоммитить:

Можно посмотреть последовательность коммитов:

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



Отложим изменения и посмотрим на текущие изменения:

Внесём какое-нибудь другое изменения:

image
Откладываем изменения:
image
Можем просмотреть список отложенных изменений с помощью команды git stash list:
image
Они нумеруются, начиная с 0.
Если мы захотим вернуть изменения, то вернется последнее изменение.
Вернём последнее изменение с помощью команды git stash pop:

При вводе этой команды выведется информация о текущем состоянии репозитория.
Добавим файлы в индекс и сделаем коммит:

Давайте выполним команду git stash pop ещё раз, чтобы вернуть изменения под номером 0:

Мы можем наблюдать изменения в редакторе Defold:

Добавим файлы в индекс и сделаем коммит:

Принцип работы stash / stash pop

Если мы используем 4 раза stash, то у нас формируется 4 изменения:

stash 0
stash 1
stash 2
stash 3

При использовании git stash pop мы достаём последние изменения в таком порядке:

stash 3
stash 2
stash 1
stash 0

Добавим какое-нибудь изменения, удалим блок кода:


Проверим изменения:

Выполним команду git stash:
image
Выполним команду git stash list:
image
Если нам нужно будет выбросить изменение, воспользуемся командой git stash drop:
image
После drop идёт 0, потому что у нас stash имеет значение 0.

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


Сделаем git stash:

Перейдём в другую ветку:
image
Выполним git stash pop:

Обратите внимание, теперь мы находимся в ветке main и изменения находятся в этой ветке.

Список команд:

  1. git stash
    Сохраняет незакоммиченные изменения (модифицированные файлы и индекс) в стэш (временное хранилище) и возвращает рабочую директорию к чистому состоянию.

  2. git stash list
    Показывает список всех сохранённых стэшей с их индексами (например, stash@{0}, stash@{1}).

  3. git stash pop
    Применяет последний стэш (stash@{0}) к рабочей директории и удаляет его из списка стэшей.

  4. git stash drop N
    Удаляет стэш с индексом N (например, git stash drop stash@{1}) из списка стэшей, не применяя его.

1 лайк

Слияние веток

Слияние веток в Git — это процесс объединения изменений из одной ветки (например, feature) в другую (например, main). Команда git merge интегрирует историю и изменения исходной ветки в целевую, создавая единый коммит слияния (merge commit), если есть расхождения.

Основные случаи:

  1. Fast-forward — если целевая ветка не имеет новых коммитов, Git просто “продвигает” указатель целевой ветки до последних коммитов исходной.
  2. Merge commit — если обе ветки имеют изменения, Git создаёт новый коммит, объединяющий их.
  3. Конфликты — если изменения в ветках конфликтуют, Git останавливает процесс, и конфликты нужно разрешить вручную.

Пример:
git checkout main
git merge feature

Объединяет ветку feature в main.

Слияние сохраняет историю обеих веток, в отличие от ребейза, который переписывает историю.

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


Добавим файл в индекс и сделаем коммит:

С помощью команды git log можем увидеть в ветке player два новых коммита:

Предположим, кто-то делает изменения в основной ветке main.
Перейдём в ветку main:
image
Изменим или удалим блок кода в каком-нибудь файле:

Сохраним изменения, добавим в индекс и сделаем коммит:

Попробуем сделать слияние веток, player в main. Используем команду git merge player:
image


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

Если мы введём команду git log, то увидим в этой ветке коммиты с ветки player и коммит слиния:

Теперь попробуем внести изменения в ветку main и сделаем слияние в ветку player. Создадим файл в ветке main:


Убедимся в том, что мы находимся в ветке main:

Добавим файл в индекс и сделаем коммит:

Теперь перейдём в ветку player:
image
Теперь выполним команду git merge с указанием той ветки, которую будем вливать в текущую:

Если мы выполним команду git log, то увидим все коммиты ветки main, нажимая “Пробел”:

Разрешение конфликтов

Конфликт в Git — это ситуация, когда Git не может автоматически объединить изменения из двух веток (или коммитов), потому что они изменяют одну и ту же часть файла по-разному.

Когда могут возникать конфликты слияния:

  • git merge
  • git stash pop
  • git pull
  • c другими редкими командами…

Внесём изменения в файле, в ветке player:


Сохраним изменения в файле. Добавим файл в индекс. Сделаем коммит:
image
image
Вернёмся теперь в ветку main:
image
В этом же блоке кода сделаем изменения, которые будут явно конфликтовать с теми изменениями, сделанными в ветке player:

image
Вольём изменения из ветки player в ветку main. У нас произошёл конфликт:
image

Строки кода между <<<< HEAD и ==== являются текущими изменениями, а строки между ==== и >>>>, изменения из другого файла.

Оставим изменения из ветки main:
image
Сохраним изменения в файле(ctrl + S).
Проверим изменение файлов в репозитории:

Git предлагает добавить файл в индекс и/или сделать коммит.
Добавим в индекс измененный файл:

Сделаем коммит:

1 лайк

Запрос на слияние

— это запрос разработчика на слияние ветки, в которой он выполнил свою задачу, с основной (базовой) веткой проекта.

Зайдём в pull request:



Попробуем слить ветку camera в ветку main:

Стрелка показывает направление слияния.
Зеленая кнопка, при нажатии, создаст запрос на слияние:

Внизу показана история коммитов, которая получится после слияния;

Выведется итоговая версия всех файлов файлов после слияния:

Создадим pull request:

Просмотрим все pull request:

Перейдём в camera:

Здесь можно посмотреть информацию о слиянии веток.
Conversation — обсуждение нашего pull request:

Коммиты, которые доступны в pull request:

В Checks можно посмотреть автоматические проверки кода:

В File changed можно посмотреть итоговые измененные файлы:

Красным цветом показаны строки, которые будут удалены.
Зеленым цветом показаны строки, которые будут добавлены.

Можно оставить комментарий к любой точке кода:



Во вкладке Conversation можно сделать слияние pull request:



В Git существуют три основных подхода к слиянию веток: Create a Merge Commit, Squash and Merge, и Rebase and Merge.

Create a Merge Commit (Обычное слияние с коммитом слияния)

  • Git создаёт специальный merge commit, который объединяет историю двух веток, сохраняя все коммиты из обеих веток.

Squash and Merge (Сквош и слияние)

  • Все коммиты из сливаемой ветки объединяются в один коммит, который затем добавляется в целевую ветку.

Rebase and Merge (Ребейз и слияние)

  • Коммиты из сливаемой ветки “переписываются” так, будто они были сделаны поверх текущей ветки, создавая линейную историю без merge-коммита.

Выберем 3 вариант:

Мы можем также удалить ветку:




Ветки camera больше нет:

Модели ветвления

Зачем нужны модели ветвления

  1. Единые принципы работы в команде
  2. Быстрый deployment

Две основные модели ветвления

  1. Git Flow

    • Основная идея: Использует несколько веток для структурированной разработки.
    • Основные ветки:
      • main — стабильная версия (готовая к релизу).
      • develop — интеграция новых фич перед релизом.
      • feature — для разработки отдельных функций.
      • release — для подготовки релизов (фиксы, тегирование).
      • hotfix — для срочных исправлений в main.
    • Плюсы: Чёткая структура, подходит для больших проектов с регулярными релизами.
    • Минусы: Сложность, избыточность для маленьких команд.
  2. TBD (Trunk-Based Development)

    • Основная идея: Разработка ведётся в одной основной ветке (trunk или main) с короткоживущими ветками для фич.
    • Основные ветки:
      • main — главная ветка, всегда готова к деплою.
      • Короткие ветки для фич/исправлений, быстро сливаются в main.
    • Плюсы: Простота, поддержка CI/CD, подходит для частых деплоев.
    • Минусы: Требует хорошей автоматизации тестирования, может быть сложно для больших команд.

Выбор модели зависит от размера команды, частоты релизов и уровня автоматизации. Git Flow — для сложных проектов, TBD — для быстрых и гибких.

Просмотр изменений

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

В коде одного файла перед коммитом:

Изменим файл в какой-нибудь ветке:


Чтобы увидеть эти изменения, нужно выполнить команду git diff и указать имя файла:


Мы видим удаленные строки кода из этого файла, нажимайте “пробел”, чтобы просмотреть дальше изменения в файле. Клавиша q — выйти из режима просмотра.

[details=В проекте перед коммитом]:
Изменим ещё один какой-нибудь файл(я удалю блок кода и добавлю комментарий):


Просмотрим статус репозитория:

Просмотрим код всех изменений, выполнив команду git diff:

Зеленым цветом отображаются добавленные строки.
Закоммитим всё изменения:

В файле между коммитами:

С помощью команды git log можно просмотреть историю коммитов:


С помощью команды git diff [hash-commit] [hash-commit] [имя файла] просмотрим изменения между ранним и поздним коммитами в файле camera.script:

В проекте между коммитами:

С помощью команды git diff [hash-commit] [hash-commit]:


Первым указывается более ранний коммит, вторым более поздний.
Если поменяем хэши-коммитов местами, то изменения покажутся в обратном порядке:

Кстати, хэш-коммитов можно указывать не полностью, можно указывать несколько первых символов:

В разных ветках:

Сейчас находимся в ветке main:


Просмотрим историю коммитов и выберем какой-нибудь коммит. Возьмём этот:

Перейдём в другую ветку:

Сравним два этих коммита:

Через пробел можно продолжить просматривать изменения:

Можно также просматривать, что было добавлено или изменено.
Добавлен файл cursor.script.
image
Удалён файл control.script:

Список команд:
  • git log
    Показывает историю коммитов в текущей ветке (хэш, автор, дата, сообщение).

  • git status
    Отображает состояние рабочей директории: изменённые, добавленные, неотслеживаемые файлы и текущую ветку.

  • git diff <file>
    Показывает изменения в указанном файле по сравнению с последним коммитом.

  • git diff
    Показывает все изменения в рабочей директории и индексе по сравнению с последним коммитом.

  • git diff <commit>
    Показывает различия между указанным коммитом <commit> и текущим состоянием рабочей директории.

  • git diff <commit1> <commit2>
    Показывает различия между двумя указанными коммитами.

  • git diff <commit1> <commit2> <file>
    Показывает различия в указанном файле <file> между двумя коммитами.

  • git diff <file1> <file2>
    Сравнивает два указанных файла в рабочей директории или индексе.

  • git blame <file>
    Показывает, кто и когда изменял каждую строку указанного файла (автор, коммит, дата).

Также, просматривать изменения можно в средах разработки или с помощью программы GitHub Desktop…