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

Git.3: создание репозиториев

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

GitLab, который мы использовали в примерах из первой заметки является удалённым сервером, со своими пользователями и их правами. В примерах этих статей мы будем заливать изменения в репозиторий. У вас это не получится сделать с моим репозиторием. Для этого нам понадобилось бы учиться создавать пользователей на GitLab'е, мне давать вам права разработчика и/или публиковать свой ssh-ключ и пр. В будущих заметках мы, возможно, будем учиться как этому так и прочему функционалу GitLab'а. Пока наша задача быстро начать работать на равных с другими коллегами (и не потерять лицо перед ними). 

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

Репозиторий создаётся следующим образом. Создайте каталог с названием вашего репозитория, добавив к нему «.git» и перейдите в него, например:

mkdir GitTutor.git
cd GitTutor.git

Здесь расширение .git говорит о том, что создаваемый каталог будет Git-директорией, той, о которой мы говорили в первой статье. Здесь важно понять — созданный выше каталог не является каталогом с вашим проектом, в него не нужно класть ваши файлы (!).  Далее создайте пустой репозиторий следующей командой (в вашей Git-директории GitTutor.git):

git init --bare (здесь два минуса перед bare)

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

cd WorkingDirectory

git clone /Path/To/RepositoryName.git
cd RepositoryName

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

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

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

Git.2: работа с изменениями

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

Первое — зафиксировать изменения в системе контроля версий (коммит):

git commit -am "Описание коммита"

Эта команда запишет ваши изменения в локальную базу Git'a. Ключ -a означает что нужно записать изменения всех файлов. Следует пользоваться этим ключом с осторожностью — если вы не хотели сохранять в базе изменения в некоторых файлах (например, те файлы, которые не компилируются на данный момент), то ключ -a запишет и эти файлы. В таком случае нужно указать имена файлов, изменения которых нужно зафиксировать. Ключ -m - означает указать сообщение. Если не указывать ключ -m (и последующее описание коммита, соответственно), то Git запустит редактор, в котором вам будет предложено ввести описание коммита. Пример коммита файлов поштучно:

git commit -m "Добавлены файлы main.c, main.h" main.c main.h

Пользоваться ли редактором для внесения комментария к коммиту или вводить его с ключом -m — личные предпочтения каждого. Лично я предпочитаю задавать комментарий в командной строке.

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

Теперь рассмотрим ситуацию когда вам нужно добавить новый файл в репозиторий. Если вы просто создадите файл в каталоге репозитория и сделаете commit -a, Git не запишет его в систему контроля версий (более того — вас даже не предупредят о том, что файлы были проигнорированы). А если вы сделаете commit с указанием конкретного имени нового файла, Git и вовсе выдаст ошибку. Для того чтобы Git начал считать этот файл частью репозитория, нужно сделать следующее:

git add список_имён_файлов

Если нужно добавить несколько новых файлов, можно использовать ключ -A. Что ещё более замечательно — этот ключ не только добавляет файлы, но и удаляет и перемещает (помечает к удалению или перемещению). Если быть точнее — этот ключ приводит репозиторий в соответствие с существующим деревом каталогов, что удобнее, чем добавлять, удалять и перемещать файлы поштучно вручную отдельными командами Git'a.

git add -A

NB!

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

Здесь нужно сделать commit (без ключа -a). В ситуации когда было изменение репозитория (добавлены или удалёны файлы) нужно зафиксировать изменения:

git commit -m "Добавлены файлы ... удалены файлы... перемещены файлы..."

Если вы не закоммитите изменения репозитория (добавленные файлы), то в последствии, когда вы измените содержание файла(-ов) и попытаетесь коммитить и добавление файла и его изменение, будут проблемы. Git закоммитит файл в том состоянии, в котором он был на момент выполнения git add. Это нормально и является следствием концепции Git'а, вглубь которой мы сейчас не полезем.

NB! Важно.

О частоте коммитов и их названиях. Не ленитесь делать коммиты в базу и осмысленно их комментировать. Лично я рекомендую фиксировать изменения являющиеся какими-то этапами — например, созданы файлы, добавлены основные шаблоны, завершена сложная функция. Называть их рекомендую соответственно — «добавлены файлы main.c, main.h», «добавлен отладочный вывод». В случае, если «сложная функция» оказалась очень большой, прогресс в процессе работы над ней можно коммитить соответственно подфункциям. Когда я совсем никак не могу найти оправдание коммита, я называю его «Operating commit» (что означает «операционный коммит»).

Итог

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

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

Git: базовые функции или как не потерять лицо перед коллегами (введение, клонирование)

"Repository — a place where things are or may be reposited,
or laid up, for safety or preservation."
Daniel Webster 1913 dictionary

Git.1: введение, клонирование

Предупреждение: эта заметка будет объёмнее, чем последующие, так как здесь будут даны общие данные и расписаны некоторые понятия. Наберитесь терпения.

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

Сам я ощутил потребность в подобном источнике информации, когда я устроился на новую работу, в достаточно большой коллектив, где Git действительно использовался для командной работы, а не как система архивирования, что не редко встречается. Меня хотели быстро подключить к проекту, сказали забрать репозиторий и прислали ссылку на него. А я не только не помнил, что с этим делать - я даже не мог вспомнить, когда выкачивал репозиторий в последний раз! В памяти всплывали только команды commit и push (это мы делаем несколько чаще, чем выкачиваем репозитории). Я с ужасом осознал, что это — всё, что я знаю о Git'е на данный момент. Тут я подумал, что хорошо бы было иметь памятки, неглубокие, но содержащие нужный минимум, и в которые можно было бы заглядывать по мере необходимости. Это и побудило меня записать и опубликовать информацию для коллег. 

Кому ещё могут быть полезны эти заметки?

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

Знакома какая-то из вышеописанных ситуаций? Тогда читайте — это для вас.

Перед тем как начать, укажу общие сведения:

• Для примеров я буду использовать сервис GitLab. Почему я выбрал его? Потому что этот продукт включает в себя Git-сервер и достаточно серьёзную надстройку над ним в виде bug-, issue-трекинга и иных инструментов. Если мы в этих заметках будем касаться какого-то функционала этого сервиса (помимо самого Git'а) — знакомство с ним будет плюсом вашей (и моей) карьере, так как GitLab нередко используется как внутрикорпоративная система во многих компаниях (даже в IBM, Sony и NASA!).
• Для доступа к моим учебным репозиториям не будет запрошен пользователь и пароль - все они настроены как «публичные».
• Структура этих заметок будет примерно следующая: описание рассматриваемой проблемы или постановка задачи, её решение в простых терминах, затем, опционально: заметки о дополнительных нюансах, потенциальных ошибках, возможностях и более подробная техническая информация.
• Прошу вас сообщать мне о допущенных ошибках или упущениях (терминология, аспекты, и пр.). Не стесняйтесь задавать дополнительные вопросы. Так же буду благодарен за предложения тем, которые вы считаете уместным рассмотреть.

Начнём с самого первого нашего контакта с системой Git — как скачать репозиторий?

git clone https://gitlab.com/daftsoft/StartProject.git

Эта команда создаст каталог с названием проекта без расширения (.git), в нашем случае — StartProject, и скачает последнюю версию репозитория в этот каталог.

NB!

В терминологии (и в идеологии) Git'а скачивание репозитория называется «клонированием». Впрочем, не во всех коллективах используют этот термин, нередко говорят «скачать».

NB!

Если вас не устраивает имя проекта по-умолчанию (имя проекта Git'а без .git), вы можете склонировать репозиторий в каталог с указанным именем:

git clone https://gitlab.com/daftsoft/StartProject.git LocalProjectDirectory

Если в проекте есть субмодули (уточните это у старших в отделе или у начальника/руководителя), нужно использовать ключ --recurse-submodule

git clone https://gitlab.com/daftsoft/StartProject.git --recurse-submodules

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

git submodule init
git submodule update --remote Submodule (Submodule — имя субмодуля)

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

Всё. Вы можете начинать работать с кодом — изучать, компилировать, отлаживать.

Git может работать по двум протоколам — https и ssh.

Примеры ссылок (адресов репозиториев): 

HTTPS:
https://gitlab.com/daftsoft/StartProject.git

SSH:
git@gitlab.com:daftsoft/startproject.git

NB!

Потенциальная почва для ошибок, которые трудно заметить.

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

.git на конце ссылки консольный Git добавляет сам — её можно опустить.

NB!

Вы уже могли догадаться, что Git должен где-то хранить служебную информацию — историю изменений, авторов и прочее. Да, вся служебная информация Git'а хранится в каталоге .git («скрытый» каталог в UNIX-системах). Каталог, в котором расположен .git называется git-директорией. Пока (а лучше никогда) залезать в него не надо — и у вас всё будет работать.

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