Про 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, где я пишу про будни разработчика.
Про учет электроэнергии
Вот эта история напомнила мне времена работы на Саранском приборостроительном заводе. Мы разрабатывали и производили электронные счетчики электроэнергии. В полном соответствии с "кто что охраняет, тот то и имеет" отдельные ушлые товарищи умудрялись делать себе "кастомные" счетчики. Нет, никакого воровства, с этим было строго - всё официально покупалось. Но таскать эти приборы на поверку было категорически противопоказано: они занижали потребление на 20-30-40%, а у особо умелых - вдвое-втрое.
Я как-то прохладно относился к этому развлечению, но когда собрался увольняться, коллеги стали подкалывать, мол "что же ты, без такого модного сувенира свалишь?", и я решил тоже запилить "экономичный счетчик". Но, будучи программистом, подошел к задаче с иной стороны. Не стал ковырять железо, как все, а решил модифицировать прошивку. Это позволяло сделать "доработку" практически необнаружимой. В общем, сделал я себе такой счетчик, выкупил, и положил в ящик стола.
Потом был переезд в другой город, смена работы... Примерно через год мне звонят с завода, и как-то застенчиво интересуются, не помогу ли я им разобраться с одной непонятной ситуевиной: в одном из райцентров Мордовии по гос. программе ставили наши счетчики (в количестве несколько тысяч штук), и вскоре обнаружилось, что все они считают на треть меньше положенного. Попросту говоря - весь поселок невольно тырил электричество. Начинаю выяснять подробности, и узнаю, что:
- эталонная прошивка для счетчиков по стечению обстоятельств оказалась утеряна
- диск с рассортированными исходниками, который оставил при увольнении, тоже то ли утерян, то ли поврежден
- прошивку сгенерировали из того, что нашли на моем рабочем компе. Посмотрели по дате, и выбрали самый свежий проект
Ни на одном этапе поверки никто ничего не заметил, и вообще, всплыло всё это только через несколько месяцев, когда обнаружилось, что через общедомовые счетчики проходит в полтора раза больше электричества, чем через квартирные. В итоге завод за свой счет менял все приборы, а IT-служба завода освоила системы контроля версий. А свой счетчик я в итоге подарил кому-то из родственников, а те его передарили дальше
Контроль версий
Уволился 2 дня назад из-за контроля версий. Много лет внедрял Git. Сделал сервер, воспитал кучу программистов, насоздавали около 30 репозиториев. И тут начальник говорит: "нашей организации больше подходит SVN".









