CodeX Editor

<h2>Введение</h2>
 На днях я получил очередной проект по разработке личного кабинета. Как обычно, я открыл консоль, чтобы посмотреть историю проекта, ветки и все ли правки закомичены (от слова commit - фиксировать). Однако ничего из этого я не узнал — проект не содержал .git репозитория. Эта ситуация в очередной раз заставила задуматься о том, как много разработчиков до сих пор не понимают необходимость контролировать изменения в файлах с исходным кодом. А многие и вовсе не знают что это такое, и как этим пользоваться.

<h2>Почему нужно использовать систему контроля версий</h2>
 Основные преимущества:
 <ul>
 <li>одновременная работа нескольких человек над проектом</li>
 <li>возможность быстро обнаружить и откатить, все не зафиксированные изменения</li>
 <li>возможность быстро откатить ошибочные, уже зафиксированные, изменения</li>
 <li>история всех изменений в проекте, с указанием даты и авторов</li>
 <li>возможность изучить процесс развития проекта</li>
 </ul>

<h2>Что такое git</h2>
 git — распределенная система контроля версий файлов. «Распределенная» значит, что каждый репозиторий содержит всю историю изменений, и из него можно развернуть полноценную рабочую копию проекта. <h2>Основные термины и понятия при работе с системой Git</h2> Репозиторий — дерево изменений проекта. После создания нового репозитория дерево содержит только одну ветку — master. Ветка состоит из коммитов, расположенных в хронологическом порядке. Как правило, в ветке master находятся проверенные и протестированные изменения. Ветка — указатель на коммит.   На один коммит может указывать несколько веток. Как правило это случается при создании новой ветки из текущей. Например для реализации в ней новой задачи. По мере добавления коммитов — ветки будут расходится в разные стороны. Коммит (от слова commit - фиксировать) — логическая единица изменений. Каждый из них имеет историю уникальный ID и цепочку предшествующих коммитов. Можно «откатить» (отменить) изменения любого из коммитов. Для любого коммита из истории можно создать указатель, то есть ветку.  Индекс — изменения, которые будут зафиксированы при следующем коммите. При этом, во время коммита, могут быть изменения, не добавленные в индекс — они не будут закоммичены. Их надо будет отдельно добавить в индекс и зафиксировать. Таким образом, можно вносить разом, все необходимые по мере работы, правки и фиксировать их логическими группами. В первое время вам понадобятся только основные команды. Давайте рассмотрим их: <ul> <li>init — создает новый репозиторий</li> <li>status — отображает список измененных, добавленных и удаленных файлов</li> <li>branch — отображает список веток и активную среди них </li> <li>add — добавляет указанные файлы в индекс</li> <li>reset — удаляет указанные файлы из индекса</li> <li>commit — фиксирует добавленнные в индекс изменения</li> <li>checkout — переключает активную ветку; отменяет не добавленные в индекс изменения</li> <li>merge — объединяет указанную ветку с активной </li> <li>log — выводит список последних коммитов (можно указать количество и формат)</li> </ul> <h2>Примеры команд для работы с Git</h2> Создайте новую папку для тестового проекта. Чтобы начать работу с гитом, надо его инициализировать — открыть консоль, перейти в корневую папку проекта и выполнить команду: <code>$ git init</code> Эта команда создаст новый пустой репозиторий. Проще говоря, появится папка .git с какими-то непонятными файлами. Причем такой репозиторий, который находится в папке проекта, файлы которого вы можете менять — называется «рабочей копией». Существуют еще «внешние копии» или bare-репозитории. Все остальные команды можно вызывать в корневой папке или в одной из вложенных. Теперь можно вносить изменения. Список изменений можно увидеть выполнив команду: <code>$ git status</code> В консоли появится список измененных файлов. Добавьте файлы, изменения в которых вы хотите зафиксировать: <code>$ git add file_name_a.php</code> Файлы можно указывать через пробел. Все файлы в данной папке и ее подпаках можно добавить командой: <code>$ git add .</code> Будьте внимательны, эта команда не добавит новые файлы в индекс. Добавятся только модифицированные старые файлы и удаленные. Новые файлы можно добавить явно указав имя.  Добавить все новые и измененные файлы можно командой: <code>$ git add -A</code> Изменения стоит фиксировать логическими блоками, то есть в одном коммите должны быть файлы связанные с решением одной конкретной ошибки или одной конкретной новой задачи. Если вы добавили файл из другого логического блока, удалите его из индекса командой: <code>$ git reset file_name_b.php</code> Зафиксируйте эти изменения в другом коммите. Так будет удобнее при просмотре истории изменений и отмене изменений. Если вы случайно изменили не тот файл - верните его к последнему зафиксированному состоянию командой: <code>$ git checkout file_name_c.php</code> Отменить изменения всех, ранее существующих, файлах в данной и вложенных папках можно командой: <code>$ git checkout -- .</code> Ненужные новые файлы достаточно просто удалить. Или это можно сделать командой: <code>$ git reset --hard HEAD</code> Проект будет полностью приведен к последнему зафиксированному состоянию. Теперь зафиксируйте изменения добавленные в индекс: <code>$ git commit</code> Откроется текстовый редактор по-умолчанию для того, чтобы добавить комментарий к коммиту. Распишите, что и зачем вы меняли. Но не перечисляйте список измененных файлов — гит сделает это за вас. Комментарий должен коротким и понятным, например: <code>fix| order price</code> <code>now price includes vat</code> Комментарии лучше писать на английском языке, в первую очередь потому, консоль может не поддерживать кириллицу и вместо описания будут кракозяблики. Первая строка самая важная и должна включать суть коммита в нескольких словах. Дальше можете не жалеть строк и расписать подробно что, зачем и почему было изменено (речь про логику, а не про файлы). Теперь можно посмотреть историю изменений, ваш коммит должен в ней отобразиться: <code>$ git log</code> <h2>Заключение</h2> Как видите, ничего сложного. Конечно это далеко не все, что может гит, но именно этого мне не хватало в свое время для того, чтобы начать пользоваться системой контроля версий. </div>