Про git и инструменты работы с ним. Часть первая. База. Это надо знать.

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

Если вы, судари, немного балуетесъ программированием (да, есть такие индивиды) в гордом одиночестве и в вашем проекте совмещаете должность мидла/техлида/CEO/бубео/секретарши и уборщицы, то вы можете обойтись без этого вашего гита. Я так делал, было дело. Теперь представим, что у вас появился единомышленник.

Вы вместе с вашим единомышленником (хах) работаете над единой кодовой базой, но, допустим, над разными модулями. Как в этом случае синхронизировать изменения кода между вами? Можно скидывать друг другу файлы, в которых произошли изменения. И да, это даже будет работать. Давайте теперь представим, что появились файлы, в которые оба вносят изменения, и количества таких файлов множится, в течении развития проекта. Просто перекидываться файлами уже становится сложнее, причем сложность растет нелинейно. Появление еще одного разработчика-единомышленника еще сильнее усложнит процесс синхронизации изменений проекта и в какой-то момент это все превратиться просто в лютый кошмар.

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

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

Как ни странно, аналогия с метро вполне приемлема, ведь, как и в метро, в гит есть ветки (тадам!!!). Не буду вдаваться в дебри терминологий объяснения работы гит, просто кратенько опишу, какой практический результат вы имеете. Вот есть вас 3 разработчика в команде, каждый работает над своим модулем, и чтобы ваши изменения кода не оказывали эффект на начальный код, вы как раз и создаете ветку (branch), которая на рисунке выше представлена линией с определённым цветом. Чтобы отслеживать изменения кода вы периодически создаете коммиты (commit), узлы/точки на рисунке выше, которые по факту являются «слепком» (читал когда-то на хабре статью про гит, где именно такое определение давалось для коммита, мне понравилось) текущего состояния проекта в вашей ветке и пишите комментарий того, что именно вы сделали. Как итог, при нажатии на коммит вы видите комментарий, файлы, которых коснулись изменения, и непосредственно сами изменения.

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

А на этом пока все, первая часть финит. В следующей части затрону другие базовые команды гит (pull, push, checkout и т.д.), а также рассказу про веб-сервисы, которые поддерживают гит и добавляют свои приятности в работу.

Ну и не забываем, я жеж вайб-мать-его-кодер и разработал чат-рулетку в виде мини-приложение в telegram, как говорится welcome t.me/Socionyx_Bot/socionyx. Затестите, вам не сложно, мне приятно!!!))).

Ссылка на мой telegram канал t.me/socionyxchannel, you are welcome too, где я пишу про будни разработчика.