Главная › Интернет › Основы работы с git. Использование слепков, а не патчей. Переключение между ветками

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

Работа с Git репозиториями

Почему Git

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

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

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

Общие сведения о Git

Подробно о работе с Git, что это такое можно прочитать в Git Book по адресу http://book.git-scm.com/

В классических VCS (Version Control System) (CVS, SVN), в рабочей копии хранится текущее состояние репозитория, и базовая копия текущей ревизии. На сервере хранятся все ревизии в виде изменений от предыдущей, либо в виде полных копий каждой ревизии с вычислением разницы по запросу. Все ревизии нумеруются по порядку начиная от первой.
В случае CVS хранятся изменения и нумерая по каждому файлу независимо, в случае SVN, нумеруются изменения репозитория.
Так как SVN хранит только изменения всего репозитория, «ветки» в нем реализуются через специальную организацию файлов в хранилище. Классически, это /trunk/ для последнего кода, /branch/somename/ для веток. Для создания ветки, делается копия /trunk/ в /branch/somename/, над которым уже работает разработчик.
При этом, при каждом коммите, идёт обращение к центральному репозиторию, для сохранения изменения, отрабатывают скрипты на сервере, идет непрерывная нумерация изменений, запрос истории так же требует обращения на сервер и т.д.

Git относится к классу DVCS (Distributed Version Control System). При этом рабочая копия содержит все коммиты, историю, ветки, всё необходимое для ведения разработки без обращения к какому-либо серверу. Для синхронизации изменений между разными копиями репозитория, в нужный момент делается pull чтобы скопировать изменения удалённого репозитория к себе, либо push чтобы скопировать локальные изменения в удалённый репозиторий. В случае с Git, каждый коммит имеет уникальный ID в виде хеша, содержащий в себе все файлы, относящиеся к нему.

Каждый коммит имеет один коммит-родитель, и, возможно, коммит-источник слияния. Таким образом, коммиты представляют собой дерево наборов файлов. «Веткой» является указатель на какой-либо коммит. Таким образом, чтобы создать ветку, нужно просто дать имя какому-либо коммиту. Чтобы слить две ветки, одна из которых начинается с конца другой, можно просто передвинуть указатель второй ветки на новый коммит (это называется Fast-Forward).

Чтобы поддерживать «плоскую» основную ветку (master), используется техника ребейза веток перед слиянием, и слияение без fast-forward"а.

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

Если теперь сделать слияние этой ветки с исходной, указатель головы исходной ветки будет просто передвинут на новое место, и мы потеряем информацию о том, что вообще существовала новая ветка. Именно поэтому используется слияние без fast-forward"а. При этом, даже если новая ветка начинается с конца предыдущей, создаётся специальный merge-commit, содержащий информацию о том, что в этом месте сливается текущая ветка с дополнительной.

Алгоритм работы над задачей

Стандартный алгоритм работы над какой-либо задачей выглядит так:

Создаётся ветка, основывающаяся на последней копии master ветки. Название новой ветки содержит класс задачи, краткое описание, номер задачи в БТ. Например feature/sessions_add_datetime_filter.5503
Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит. Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.
После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка ребейзится относительно последнего мастера, и пушится в центральный репозиторий.
Второй человек, работающий над тем же проектом, делает к себе pull центрального репозитория. Если он уже смотрел – то удаляет свою локальную копию ветки, после чего переключается на указанную ветку. Прочитывает код, проверяет его работоспособность, после чего либо отдаёт на доработку, если там обнаружены проблемы, либо делает еще раз rebase поверх мастера, и слияние ветки с мастером.
После слияния с мастером, ревьюер пушит новый мастер в центральный репозиторий, удаляет у себя локальную ветку задачи, пушит в мастер удаление ветки задачи.
Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master.

Правила ведения чистых коммитов

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

Автором должен быть прописан разработчик – Имя, Фамилия, рабочий e-mail.
Текст комментария должен содержать краткое описание изменения. Для зарубежных проектов описание обязано быть на английском языке, для проектов российского бранча приемлемо комментировать на русском.
Коммит не должен содержать в себе файлы, не относящиеся к изменениям. Если ваша IDE, OS, какой-то плагин какому-либо софту использующемуся при разработке создают технические файлы, либо добавьте их в.gitignore, либо не добавляйте к коммиту, либо удаляйте перед коммитом.
Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот – меняйте настройки редактора или перед коммитом приводите всё к виду «как было».
Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами.
Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии.

Работа под Windows

Для работы с Git под Windows самое удобное – использовать TortoiseGit. Однако следует знать, что на 2017 год есть более удобный инструмент - SmartGit.

Подготовка к работе

Устанавливается putty со страницы http://www.chiark.greenend.org.uk/~sgtatham/putty/
Лучше всего ставить полный пакет, со всеми программами. По надобятся как минимум plink, puttygen.
Устанавливается msysGit из проекта http://code.google.com/p/msysgit/
Выбрать опции при установке «Add “Git Bash here”», «Run Git from the Windows Command Prompt», «Use Windows style line endings», когда спросит – дать путь до plink.exe
Устанавливается TortoiseGit из проекта http://code.google.com/p/tortoisegit/
После установки зайти в TortoiseGit → Settings → Git → Config, убедиться что путь до msysgit задан, и что опции AutoCRLF и SafeCRLF установлены, настроены имя, фамилия, email разработчика.
С помощью puttygen создаётся пара приватный+публичный ключ.
Публичный ключ высылается админам для добавления в доступы репозиториев и серверов.
Приватный ключ добавляется в pagent через клик правой кнопкой → add key.

Получение репозитория

В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой→TortoiseGit→Clone, вводим адрес центрального репозитория
ssh: //git@ СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
В поле «Load Putty Key» выбираем путь до приватного ключа.

При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.

Стандартные процедуры работы

«Начало работы над задачей»

,
Branch: master
Меню → TortoiseGit → Pull
Меню → TortoiseGit → Create Branch
Name Branch: название новой ветки
Base On: HEAD (master)
[x] Switch to new branch
«Коммит очередного кусочка работы»

Меню → Git commit -> “имя ветки”
Отметить файлы, только нужные для данного конкретного коммита
Обязательно щелкнуть на «View Patch», и убедиться
в соответствии правилам ведения чистых коммита
В message ввести описание изменения, соответствующее правилам
Меню → TortoiseGit → Push
Выбираем в Local сперва master, потом нашу текущую ветку.
Remote заполняется при этом автоматически.
Название remote ветки должно быть идентично local
«Ребейз относительно мастера»
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
Меню → Git Sync
Local branch: master
Remote branch: master
Правая стрелочка вниз у первой кнопки (Pull по умолчанию), Fetch
Меню → TortoiseGit → *Rebase
Branch: текущая ветка
UpStream: master
Если будут конфликты – разобраться с ними через вкладку «Conflict File»
На выбор, правой кнопкой файла, утилиты
Edit Conflicts – позволяет по каждому расхождению выбрать
использовать версию какую блока
Resolve Conflicts Using
theirs – использовать версию мастера
mine – использовать версию текущей ветки
Open – открыть в редакторе, и исправить вручную
После исправления сделать Resolve
После исправления всех конфликтов нажать Commit
После ребейза нажать Done
«Кратковременное сохранение состояния изменений»

Меню → TortoiseGit → Stash Save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
Меню → TortoiseGit → Stash Pop
«Длительное сохранение состояния изменений»

Меню → Git Commit -> “ветка”
Отмечаем все-все изменения (Select/Deselect All)
В текст сообщения пишем «Partial commit»
Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
Меню → TortoiseGit → Show Log
Выделяем коммит, который идет в дереве сразу перед «Partial commit»
Правой кнопкой → Reset <ветка> to this
Reset type: Mixed
«Ревью ветки»

Меню → TortoiseGit → Switch/Checkout
Branch: master
Меню → TortoiseGit → Pull
Меню → TortoiseGit → Switch/Checkout
Branch: remotes/origin/нужнаяветка
[x] Create new branch: нужнаяветка
[x] Force
[x] Track
[x] Override branch if exists
Меню → TortoiseGit → *Rebase
Branch: нужнаяветка
UpStream: master
Ветка ветка должна быть «up to date» или заребейзится без конфликтов.
== Анализируем изменения просмотром лога изменений через
Меню → TortoiseGit → Show log
и смотрим изменения от master до последнего
== Смотрим общее изменение относительно мастера
Меню → TortoiseGit → Diff with previous version
Version 1: HEAD
Version 2: master
== если всё хорошо, делаем
Меню → TortoiseGit → Switch/Checkout
Branch: master
Меню → TortoiseGit → Merge
From: нужнаяветка
[x] No fast forward
Сообщение не редактируем.
Меню → TortoiseGit → Push
И удаляем ветки:
Shift + Меню → TortoiseGit → Browser Reference
в дереве слева Refs => heads => находим ветку, правой кнопкой, Delete branch
в дереве слева remotes => origin => находим ветку, правой кнопкой,
Delete remote branch

Работа под Linux

Подготовка к работе

Устанавливаются системные пакеты ssh-client и git
Создаётся приватный ключ:
ssh-keygen -t dsa -C "Ivan Petrov "
Настраивается ФИО и Емейл автора:
git config --global user.name "Ivan Petrov"
git config --global user.email work@mail"
Админу отсылается файл ~/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.

Получение репозитория

Переходим в директорию для работы, и запускаем

git clone ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git

Основные используемые функции

Обновление текущей ветки из центрального репозитория:
git pull
Отправка текущей ветки в центральный репозиторий:
git push origin branchname
Переключение на некоторую ветку:
git checkout branchname
При переключении на ветку, которой еще нет в локальном репозитории, будет создана локальная ветка, связанная с удалённой.
Создание новой ветки, базирующейся на текущей
git checkout -b branchname
Удаление веток
git branch -d branchname == удаление локальной уже слитой ветки
git branch -D branchname == принудительное удаление локальной ветки
git push origin:branchname == удаление ветки с центрального репозитория
Слияние ветки с текущей
git merge --no-ff branchname
Посмотреть какие файлы изменены в текущей директории:
git status
Просмотреть текущие изменения:
git diff
Сохранение текущих изменений:
git add именафайлов == добавить измененные/созданные файлы/директории
git rm именафайлов == добавить удаление файла/директории
git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

Стандартные процедуры работы

«Начало работы над задачей».
Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
git checkout master
git pull
git checkout -b branchname
«Коммит очередного кусочка работы».
Выполняется после выполнения некого изменения, суть которого целостная.
# проверяем, какие файлы изменились к текущему моменту
# удаляем если что-то попало совсем лишее
git status
# смотрим текст изменений, на предмет соответствия
# правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
git diff
# если какие-либо файлы не должны попасть в коммит (например,
# относятся к другому атомарному изменению.)
# то помечаем только те файлы, изменения которых нужно сохранить
git add …
git rm …
# сохраняем. -m можно опустить, тогда комментарий через редактор
git commit -m "Some commit message"
# если все на текущий момент созданные изменения нужно сохранить, то
# через git add добавляем новые файлы, а всё остальное сохраняем через
git commit -a -m "Some commit message"
«Отправка ветки на центральный репозиторий»
Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
git push origin branchname
Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
«Ребейз относительно мастера».
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены:
git checkout master
git pull
git checkout branchname
git rebase master
При возникновении конфликтов, нужно:
(*)
git status == проверить файлы, для которых есть неразрешенные конфликты.
Редактируем первый файл с конфликтом: находим в нем «<<<<<». То, что между <<<<< и ==== – содержит копию текста из master ветки, то что между ===== и >>>>> содержит текст из нашей ветки. Нужно на этом месте оставить одну единую версию, содержащую общий код и мастера и нашей ветки
git add измененный_файл
перейти на (*)
После исправления конфликтов во всех файлах, запускаем
git rebase --continue
Если конфликты несовместимые с дальнейшим продолжением ребейза
git rebase --abort == прерывает ребейз и возвращает ветку в исходное
состояние (до начала ребейза)
После ребейза обновляем состояние ветки в центральном репозитории
git push origin branchname -f
«Кратковременное сохранение состояния изменений».
Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
git stash save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние с помощью
git checkout originalbranch
git stash pop
Тем самым восстановив состояние изменения.
«Длительное сохранение состояния изменений».
Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.
git add .
git commit -m "Partial commit"
git push origin branchname
Позже, для возврата к тому же состоянию как было до, выполняется
git checkout branchname
git reset --soft HEAD^
git reset HEAD .

Важно! После такой процедуры сохранения/восстановления, при следующем
git push origin branchname
Будет выдано предупреждение о непоследовательном изменении. Чтобы принудительно отправить изменения, следует добавить опцию -f.
git push -f origin branchname
Важно: не следует добавлять -f всегда, так как это спасёт от случайных опечаток в названии ветки, например.
«Ревью ветки».
Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.
git checkout master
git pull
git branch -D branchname
git checkout branchname
git rebase master == ветка обязана наложиться без конфликтов
git diff master == изучаем разницу от мастера или общим диффом, или
git log master..HEAD == смотрим какие коммиты были между мастером и текущей веткой
Если всё хорошо, делаем:

git checkout master
git merge --no-ff branchname
git push origin master
git push origin:branchname
git branch -d branchname

Для людей естественно сопротивляться изменениям. Если Git не встретился вам, когда вы начинали работать с системами контроля версий, наверняка вы чувствуете себя комфортнее в системе Subversion (SVN) .

Часто люди говорят, что Git слишком сложен для новичков. Тем не менее, я позволю себе не согласиться с этим.

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

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

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

Установка Git

На официальном сайте Git есть детальная информация об его установке на Linux, Mac и Windows. В нашем случае, мы будем использовать в целях демонстрации Ubuntu 13.04 , где установим Git с помощью apt-get:

sudo apt-get install git

Начальная настройка

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

mkdir my_git_project cd my_git_project

Первым этапом является инициализация Git в каталоге. Это можно сделать с помощью команды init , которая создает каталог .git , содержащий всю информацию, связанную с Git для вашего проекта.

git config --global user.name "Shaumik" git config --global user.email "[email protected]" git config --global color.ui "auto"

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

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

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

Подготовка файлов для коммита

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

Проверить статус репозитория

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

Добавление файлов в Git для отслеживания

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

Добавляем файлы при помощи команды add :

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

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

git add myfile2 myfile3

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

Если вы будете использовать команду add рекурсивно, она добавит все такие файлы, если они существуют в вашем репозитории.

Удаление файлов

Но выполнение простой команды git rm удалит файл не только из Git , но также и из вашей локальной файловой системы! Чтобы

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

git rm --cached

Коммит изменений

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

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

git commit -m "My first commit"

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

Избегайте слишком общих сообщений типа «Исправлены ошибки ». Если у вас есть трекер задач, вы можете добавлять сообщения в виде «Исправлена ошибка #234 ».

Хорошей практикой является использование имени ветки или имени функции в качестве префикса к сообщению коммита. Например, «Управление активами: добавлена функция для генерации PDF файлов активов » - это содержательное сообщение.

Git идентифицирует коммиты путем добавления длинного шестнадцатеричного числа к каждому коммиту. Как правило, не нужно копировать всю строку, для определения вашего коммита достаточно первых 5-6 символов.

Обратите внимание, что на скриншоте наш первый коммит определяется кодом 8dd76fc .

Дальнейшие коммиты

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

Вы можете проверить изменения в отслеживаемых файлах, сделанные в последнем коммите, с помощью команды git diff . Если вы хотите просмотреть изменения в определенном файле, используйте команду git diff :

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

Вы можете избежать использования этой команды, воспользовавшись префиксом -a для команды git commit , который добавит все изменения в отслеживаемые файлы.

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

Если вы избирательно размещаете файлы, то заметите изменения в каждом файле. Но если вы добавите префикс -a к вашему коммиту, все файлы будут закоммичены, и вы не сможете выявить возможные ошибки.

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

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

Управление проектом

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

Так будет показана вся история проекта, которая представляет собой список всех коммитов и информации по ним. Информация о коммите включает в себя хеш-код коммита, автора, время и сообщение коммита. Есть различные варианты git log , которые вы можете изучить, как только освоите понятие ветки (англ. branch) в Git .

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

git show

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

Размещение кода в облаке

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

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

Если вы хотите разместить код в облаке, вы можете создать проект на GitHub , GitLab или BitBucket и поместить уже существующий код в репозиторий.

Надеемся, какая у вас операционная система, вы знаете. И сразу предупредим новичков: не путайте git и GitHub - это разные вещи. Нас интересует именно git, а GitHub (или ему подобные сервисы вроде Bitbucket или GitLab) - это по сути хостинг для проектов, использующих git.

Репозиторий

Итак, вот у вас уже есть git. Теперь нужно создать хранилище версий для него. Запомните, это хранилище называется репозиторий (англ. repository) - при случае можете вставить где-нибудь это словечко. В зависимости от того, какая у вас оболочка, соответствующей командой создайте новую директорию , откройте ее (в командной строке, она же оболочка, а не проводником или чем-то подобным) и выполните:

Git init

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

Git clone

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

Но если вы крутой чувак и уже работаете с удаленным сервером, то вот такая команда будет для вас в самый раз:

Git clone username@host:/path/to/repository

Лес git’а

Немного теории. Git в своей работе управляет тремя структурами, которые называются деревьями. Первое - это рабочая директория, в ней хранятся файлы, с которыми вы прямо сейчас работаете. Ну, она ж рабочая, логично. Второе - это Index, этакий чек-поинт, который позволяет вам вносить изменения и ничего не портить. А третье - это HEAD, который указывает на последний сделанный вами коммит. (Чтобы вы не запутались в терминологии: коммит (англ. commit) - это сохранение состояния проекта в репозиторий. Короче, считайте, новая версия.)

Так вот, чтобы вы не заблудились в этих трех соснах, запомните две крутые команды: add и commit. Они позволят вашей работе спокойно бродить по git’у, сохраняясь, куда надо. Если вы придумали что-то гениальное и тут же внесли изменение в рабочую копию проекта, то не спешите сразу коммитить! Сначала испытайте в Index’е, для этого выполните:

Git add [имя_файла]

если вы внесли изменение только в один файл, или

Git add *

если вы хорошо потрудились поменяли сразу кучу исходников. Изменения положительны? Хорошо потестили? Тогда скорее коммитить:

Git commit -m "Commit message"

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

Вот вам, кстати, поясняющая картинка:

Теперь файл(-ы) прочно обосновались в HEAD вашей рабочей локальной копии. Оттуда их не выгнать, но в вашем удаленном репозитории их все еще нет. Давайте сунем их еще и туда! Используйте:

Git push origin master

Только вместо master напишите название нужной ветки. Ах да, вы же еще не знаете, что такое ветки. Ну ладно, пока что запомните это место, а когда прочитаете про ветвление, вернетесь сюда.

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

Git remote add origin [сервер]

Ветвление

По-английски эта штука зовется branching - лучше как следует вникните в этот вопрос и почитайте про ветвление подробнее, я вас с ним только познакомлю. Ветвление используется для одновременной и независимой разработки разных фич (ну, или накопления большего количества багов, ведь исходного кода становится больше). Основной веткой является master - она появляется при создании репозитория. Другие ветки - это песочницы, когда достаточно в них наиграетесь, слейте в единое целое в master. Сейчас поясню, как это делается.

Создание новой ветки

Вот вы решили проработать какую-нибудь новую фичу. Создайте для нее новую ветку:

Git checkout -b [новая_ветка]

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

Переключение между ветками

Надо сделать перерыв в работе с этой фичей и переключиться на другую ветку? Используйте (если работаете с локальным репозиторием, то указывать его имя не обязательно):

Git checkout [репозиторий]/[ветка]

Ну, а если вы уже совсем не хотите с ней работать, то удалите ее совсем:

Git branch -d [ветка]

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

Git push origin [ветка]

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

Чтобы слить ветку в ту, с которой вы сейчас работаете, используйте:

Git merge [ветка]

Но, понятное дело, это все приводит к конфликтам. И это реально проблема. Так что попробуйте исправлять все ручками прямо в директории с репозиторием. Только потом не забудьте пометить, что вы их «слили»:

Git add [имя_файла]

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

Git diff [одна_ветка] [другая_ветка]

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

Git pull

Я, конечно, понимаю, что вы слишком круты, чтобы оставлять какие-либо пометки на будущее - все держите в голове - но все-таки рекомендую вам оставлять тэги. И это не моя выдумка, так делают многие:

Git tag [первые_десять_символов_соответствующего_коммита]

Вы не знаете, какие первые символы у имени нужного коммита? Не беда, смотрите в историю репозитория - его лог:

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

Система контроля версий или VCS может значительно облегчить работу разработчиков, пытающихся проанализировать изменения и вклады в общий код. Проще говоря, система контроля версий – это ключевой элемент в системе управления настройками программного обеспечения, которые отвечают потребностям проекта. VCS дают возможность назначать для определенных изменений/ревизий/обновлений буквенные или числовые значения. Также могут предоставить информацию о временных метках и идентификаторе человека внесшего изменения. В этом руководстве мы расскажем вам о самой часто используемой системе контроля версий – GIT. Вы узнаете, что такое GIT и какие он имеет преимущества перед остальными VCS, а также мы расскажем об установке GIT на разные системы и его правильном использовании.

В 2005 году, Линус Торвальдс (человек, известный тем, что стоял за созданием ядра Linux OS) разработал GIT для управления версиями ядра Linux, однако, чуть позднее его поддержкой занялся другой человек, японский инженер-программист – Джунио Хамано. На сегодняшний день, GIT – это одна из самых известных систем контроля версий с открытым исходным кодом, на которую полагаются миллионы проектов по всем миру (включая как коммерческие, так и бесплатные проекты). GIT – это полностью бесплатное программное обеспечение, поддерживающее множество ОС, таких как Mac, Linux, Windows и Solaris. Скачать соответствующие дистрибутивы можно с официального сайта GIT Вот несколько функций GIT достойных упоминания:

Распределенная система управления версиями, GIT следует принципу одноранговой сети – peer to peer (равный к равному) в отличии от других систем вроде Subversion (SVN), которая основана на модели client-server (клиент-сервер).
GIT позволяет разработчикам иметь множество совершенно независимых веток кода. Создание, удаление и объединение этих веток происходит без каких-либо проблем и больших затрат времени.
В GIT все операции атомарны; это означает, что любое действие может быть полностью удачным или провалиться (без каких-либо изменений). Это действительно важно, так как в некоторых системах контроля версий (вроде CVS), где действия не атомарны, некоторые повисшие операции по всему хранилищу, могут оставить его в нестабильном состоянии.
В отличии от других VCS, таких как SVN или CVS где метаданные хранятся в скрытых папках (.cvs, .svn, и т.д.), в GIT все данные расположены в каталогах.git.
Он использует модель данных, которая помогает обеспечить криптографическую целостность всего, что присутствует в репозитории. Каждый раз когда файлы добавляются или коммитятся, генерируются их контрольные суммы; аналогичный процесс происходит при их извлечении.
Еще одна превосходная функция, присутствующая в GIT – это его индекс . В пределах индекса, разработчики могут форматировать коммиты и просматривать их до фактического применения.

Вот пожалуй мы и ответили на вопрос “Что такое GIT”.

Он довольно прост в использовании. Для начала, вы можете либо создать новое хранилище, либо добавить существующее. После установки, команда git-init поможет вам с настройкой нового хранилища, или команда git clone поможет настроить пользователя для работающей копии локального хранилища.

Шаг 1 - Установка GIT

В данной части руководства будут показаны простейшие способы установки GIT на разные операционные системы:

Вариант 1 - Установка GIT на Windows

Установка GIT на Windows, осуществляется также просто, как и установка любого другого приложения; загрузка установщика и его запуск. Выполните данные шаги для установки GIT на Windows:

Посетите этот сайт и скачайте установщик GIT для Windows.
После загрузки, запустите установку двойным нажатием мыши. Следуйте инструкциям на экране, продолжайте нажимать Next (Далее) и наконец Finish (Финиш) для успешного завершения установки.

Запустите командную строку и впишите следующие команды в терминале:

ЗАМЕТКА! Не забудьте изменить John Smith и [email protected] на ваши собственные личные данные. Любые впоследствии созданные коммиты будут связаны с этими данными.

Это все что нужно для установки GIT на Windows.

Вариант 2 - Установка GIT на Mac

Существует множество способов для установки GIT на Mac, есть даже вероятность того, что GIT уже установлен на вашем компьютере. Eсли у вас установлен XCode; выполните следующую команду в терминале для проверки:

Git --version

Если ваш результат будет схож с таким git version 2.7.0 (Apple Git-66), тогда можете смело приступать к работе с GIT, если нет, то выполните следующие шаги:

Посетите и скачайте последнюю версию установщика для Mac.
Следуйте инструкциям установщика и завершите установку.

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

git config --global user.name "John Smith" git config --global user.email "[email protected]"

ЗАМЕТКА! Не забудьте изменить John Smith и [email protected]

Вариант 3 - Установка GIT на Linux

Если вы являетесь пользователем Linux, вы должны уметь устанавливать программы и пакеты на ваш компьютер используя простые команды apt-get или yum install; чтож, установка GIT ничем отличается:

Для пользователей Debian/Ubuntu (apt-get):

Откройте терминал и выполните следующую команду:

sudo apt-get update sudo apt-get install git

Проверьте правильности установки командой git –version.
Выполните следующие команды в терминале для настройки вашего имени пользователя и адреса электронной почты, которые будут связаны с вашим GIT аккаунтом:

git config --global user.name "John Smith" git config --global user.email "[email protected]"

ЗАМЕТКА! Не забудьте изменить John Smith и [email protected] на ваши собственные данные. Любые созданные в дальнейшем коммиты будут связаны с ними.

Fedora (yum/dnf):

Вы можете получить пакеты GIT, используя как yum, так и dnf.

Откройте терминал и выполните следующие команды:

sudo dnf install git sudo yum install git

Проверьте правильность установки командой git –version.
Выполните следующие команды в терминале для настройки вашего имени пользователя и адреса электронной почты, которые будут связаны с вашим GIT аккаунтом:

git config --global user.name "John Smith" git config --global user.email "[email protected]"

ЗАМЕТКА! Не забудьте изменить John Smith и [email protected] на ваши собственные данные. Любые созданные в дальнейшем коммиты будут связаны с ними.

Шаг 2 - Использование GIT

Теперь, когда GIT настроен на вашем устройстве Windows / Mac / Linux, давайте изучим основы GIT и то, как вы можете начать с ним работу.

Создание/настройка/клонирование репозитория:

Репозиторий является одним из самых сильных инструментов любого проекта с контролем версий. Для превращения любого каталога в репозиторий GIT поможет простая команда git init <каталог>. После выполнения команды, в месте где была выполнена команда должен появиться каталог с названием.git.

Если же у вас уже имеется каталог и вы хотите добавить (клонировать) его используйте команду git clone . Для клонирования локального репозитория используйте следующую команду:

Git clone /путь/до/локального/репозитория

Если вы планируете клонировать удаленный репозиторий используйте:

Git clone user.name@host:/путь/до/удаленного/репозитория

Если у вас есть учетная запись Hostinger, вы легко можете клонировать и управлять репозиторием через инструмент в Панели управления → GIT . К примеру, вы хотите клонировать репозиторий GIT, просто введите его адрес, выберите ветку, путь установки и нажмите кнопку Создать .

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

Рабочий процесс:

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

Команды Add и Commit:

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

Git add <имя_файла>

Если вы достаточно уверены в изменении для его коммита к HEAD , вы можете использовать команду commit. Для этого используйте следующую команду:

Git commit –m “Добавьте здесь любое сообщение описывающее коммит”

ЗАМЕТКА! Как только команда commit будет выполнена (из рабочего каталога), будет произведен коммит файла к HEAD , однако отправка на удаленный репозиторий произведена не будет, для этого используется отдельная команда.

Дальнейшее продвижение изменений:

После коммита ваших изменений (и если они готовы к отправке в оригинальный репозиторий), вы можете использовать команду push.

После выполнения команды git push origin master из рабочего каталога, все изменения присутствующие в HEAD будут отправлены на удаленный репозиторий. В вышеупомянутой команде, значение master должно быть изменено на название ветки для которой вы хотите произвести коммит изменений.

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

Git remote add origin <сервер>

ЗАМЕТКА! Замените значение в коде <сервер> на адрес удаленного сервера, который вам необходим в данный момент.

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

Ветки:

Еще одной превосходной и продвинутой особенностью GIT является возможность разработчикам и руководителям проектов создавать несколько независимых веток в рамках одного проекта. Основная цель ветки – это разработка функций, которые при этом находятся изолированно и не влияют друг на друга. Стандартная ветвь в любом проекте всегда является главной веткой. По мере необходимости, может быть создано любое количество веток, которые в конечном итоге могут быть объединены с главной веткой.

Новая ветка может быть создана с помощью данной команды:

Git checkout -b feature_n *

feature_n это имя ветки

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

Git checkout master

При помощи данной команды может быть удалена любая ветка:

Git checkout -d feature_n

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

Git push origin feature_n

Обновление и объединение:

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

Для объединения активной ветки с какой-либо другой воспользуйтесь этой командой: git merge feature_n.

Используете ли вы pull или merge, GIT всегда пытается справиться с возникающими конфликтами самостоятельно, но это не всегда у него получается. В случае неудачи выполнения команды, пользователь должен разрешить возникший конфликт вручную. После того, как вы отредактировали файлы (для устранения конфликта), пометьте их как merged с помощью команды:

Git add <имя.файла>

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

Git diff <имя_ветки_источника> <имя_целевой_ветки>

Маркировка:

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

Git tag 1.1.0 1c2d2d56fa

1c2d2d56fa в вышеприведенной команде относится к первым 10 символам commit-id, на которые ссылается тег. Идентификатор коммита или Commit ID можно найти в журнале.

Журнал:

Изучить историю репозитория можно заглянув в журнал. Команда для вызова журнала git log. Для отображения коммитов сделанных конкретным пользователем, используйте:

Git log --author =Имя

Сжатую версию журнала (один коммит на строке) можно просмотреть при помощи команды:

Git log --pretty=oneline

Для просмотра измененных файлов:

Git log --name-status

Замена локальных изменений:

Если вы каким-то образом навели беспорядок и хотите отменить изменения, сделанные в файле, произведите этот процесс с помощью следующей команды:

Git checkout -- <имяфайла>

Выполнив эту команду вы замените измененные данные в рабочем дереве на последние данные находящиеся в HEAD . Любые изменения, которые уже были добавлены в индекс не пострадают.

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

Git fetch origin git reset --hard origin/master

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

Описание

Git является для управления версиями разрабатываемых файлов. Создана она была в 2005 году автором ОС Linux. Эта система осуществляет синхронизацию работы с сайтом, а также сохраняет и обновляет изменения в файлах. Это очень удобный подход в случае работы над проектом нескольких разработчиков. На сегодняшний день во многих известных проектах используется именно Git. Что такое использование дает? К примеру, разработкой операционной системы Android занимается большое число программистов. Было бы крайне неудобно, если бы один из них вносил изменения, а другие об этом не знали. Git же позволяет всем быть в курсе всех изменений, а в случае ошибок вернуться к предыдущим версиям файлов.

Использование слепков, а не патчей

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

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

Преимущественно локальные операции

Для того чтобы совершать большинство операций в Git, нужны лишь локальные ресурсы и файлы. Это означает, что чаще всего нет необходимости в информации, находящейся на других компьютерах, входящих в сеть. Так как все изменения проекта находятся на диске, выполнение операций происходит с молниеносной скоростью. Например, для того чтобы просмотреть историю проекта, ее не нужно загружать с сервера. Она считывается из локального репозитория на компьютере. Если нужно увидеть изменения между версией файла, которая была сделана месяц назад, и текущей, можно сделать это очень быстро, не обращаясь к серверу.

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

Наблюдение за целостностью данных

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

Данные чаще всего добавляются

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

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

Работа с Git для начинающих подразумевает запоминание того, что файл может находиться в одном из трех состояний:

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

Так, в проектах, в которых используется Git, имеется три раздела для разных состояний файлов:

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

Устанавливаем Git

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

Установка Git из исходников.
Установка пакета для используемой платформы.

Установка Git из исходников

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

Для установки понадобятся необходимые библиотеки: expat, curl, libiconv, openssl, zlib. После их инсталляции можно загрузить последнюю версию системы контроля версий, скомпилировать ее и установить.

Установка в операционной системе Windows

Если у пользователя нет Linux, а хочется использовать Git, Windows также поддерживает эту систему. И установить ее очень просто. Существует проект msysGit, процедура установки которого является одной из самых простых. Необходимо просто загрузить файл инсталлятора, который можно найти на странице проекта в GitHub, а затем запустить его. По окончании установки на компьютере будет две версии - графическая и консольная.

Первоначальная настройка Git

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

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

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

Пользовательское имя

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

Если указать опцию -global, такие настройки нужно будет сделать один раз.

Выбор текстового редактора

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

Проверка параметров

Чтобы знать основы Git, необходимо уметь проверять используемые настройки. Для этого применяется config -list. Она выводит все доступные параметры, которые сможет найти. Некоторые имена настроек могут присутствовать в списке несколько раз. Это происходит из-за того, что Git считывает один ключ из различных файлов. В такой ситуации для каждого ключа используется последнее значение. Есть возможность проверять значения определенных ключей, вписав в команду вместо «--list» - «{ключ}».

Как создать репозиторий

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

Создание в данном каталоге

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

Клонирование репозитория

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

Удаление файла в Git

Удалить из системы любой файл можно, если исключить его из индекса, то есть из отслеживаемых файлов. Для этого нужна команда git rm. Она также убирает файл из рабочего каталога пользователя. Затем нужно выполнить коммит. После него файл попросту исчезнет и отслеживаться больше не будет. Если же он изменен и уже проиндексирован, то применяют принудительное удаление с параметром -f. Такой способ предотвратит удаление тех данных, которые еще не записались в снимок состояния и которые нет возможности восстановить из системы.

Отмена изменений

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

Итоги

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