Про 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, где я пишу про будни разработчика.
