Git.2: работа с изменениями
Вы скачали проект, к которому вас подключили, начали работать с ним и, как результат, наделали изменений в файлах, а может быть, уже создали новые файлы. В какой-то момент настаёт время сохранять свои изменения, то есть «залить» их в репозиторий. Рассмотрим как это делается в логичной очерёдности, которая скорее всего у вас будет возникать.
Первое — зафиксировать изменения в системе контроля версий (коммит):
git commit -am "Описание коммита"
Эта команда запишет ваши изменения в локальную базу Git'a. Ключ -a означает что нужно записать изменения всех файлов. Следует пользоваться этим ключом с осторожностью — если вы не хотели сохранять в базе изменения в некоторых файлах (например, те файлы, которые не компилируются на данный момент), то ключ -a запишет и эти файлы. В таком случае нужно указать имена файлов, изменения которых нужно зафиксировать. Ключ -m - означает указать сообщение. Если не указывать ключ -m (и последующее описание коммита, соответственно), то Git запустит редактор, в котором вам будет предложено ввести описание коммита. Пример коммита файлов поштучно:
git commit
Пользоваться ли редактором для внесения комментария к коммиту или вводить его с ключом -m — личные предпочтения каждого. Лично я предпочитаю задавать комментарий в командной строке.
Повторю то, что уже тысячи раз писалось — несмотря на то, что Git позволяет ставить пустую строку в комментарий, не забывайте описывать свои изменения (коммиты). Когда-то их наличие может спасти вас от часов головной боли.
Теперь рассмотрим ситуацию когда вам нужно добавить новый файл в репозиторий. Если вы просто создадите файл в каталоге репозитория и сделаете commit -a , Git не запишет его в систему контроля версий (более того — вас даже не предупредят о том, что файлы были проигнорированы). А если вы сделаете commit с указанием конкретного имени нового файла, Git и вовсе выдаст ошибку. Для того чтобы Git начал считать этот файл частью репозитория, нужно сделать следующее:
git add список_имён_файлов
Если нужно добавить несколько новых файлов, можно использовать ключ -A. Что ещё более замечательно — этот ключ не только добавляет файлы, но и удаляет и перемещает (помечает к удалению или перемещению). Если быть точнее — этот ключ приводит репозиторий в соответствие с существующим деревом каталогов, что удобнее, чем добавлять, удалять и перемещать файлы поштучно вручную отдельными командами Git'a.
git add -A
Имейте в виду, что, если вы привыкли хранить какие-то файлы в каталоге репозитория, но держать их вне репозитория, ключ -A вам не подойдёт, так как добавит все файлы в репозиторий.
Здесь нужно сделать commit (без ключа -a) . В ситуации когда было изменение репозитория (добавлены или удалёны файлы) нужно зафиксировать изменения:
git commit
Если вы не закоммитите изменения репозитория (добавленные файлы), то в последствии, когда вы измените содержание файла(-ов) и попытаетесь коммитить и добавление файла и его изменение, будут проблемы. Git закоммитит файл в том состоянии, в котором он был на момент выполнения git add. Это нормально и является следствием концепции Git'а, вглубь которой мы сейчас не полезем.
NB! Важно.
О частоте коммитов и их названиях. Не ленитесь делать коммиты в базу и осмысленно их комментировать. Лично я рекомендую фиксировать изменения являющиеся какими-то этапами — например, созданы файлы, добавлены основные шаблоны, завершена сложная функция. Называть их рекомендую соответственно — «добавлены файлы main.c, main.h», «добавлен отладочный вывод». В случае, если «сложная функция» оказалась очень большой, прогресс в процессе работы над ней можно коммитить соответственно подфункциям. Когда я совсем никак не могу найти оправдание коммита, я называю его «Operating commit» (что означает «операционный коммит»).
Итог
На данный момент вы умеете скачивать (клонировать) репозиторий, записывать изменения в локальную базу (вести базу версий), и добавлять в неё новые файлы.
В следующей заметке мы рассмотрим как работать с удалённым сервером Git, что вам, практически 100%-но понадобится в вашей профессиональной деятельности.
