Как най-добрите практики на Git ми спестиха часове на преработка

Наскоро работех над задачата за надграждане на сертификат за NodeJS приложение. Това е последно докоснато преди две години за подобряване на функцията. Всеки проблем на живо, повдигнат на това приложение, ще изисква незабавно внимание, въпреки че приложението се използва само вътрешно.

Приложението е старо. Core-NodeJS-Infra модулите не се актуализират повече от две години. Услугите надолу по веригата са оттеглени. Начинът, по който наричаме услугите надолу по веригата, се променя. Строгият срок е череша на тортата. Знаех, че това ще е кацане с влакчета.

Прекарах три дни в стартирането на приложението.

Инфраструктурните модули се актуализират ли? Проверете.

Услугите надолу по веригата работят добре? Проверете.

UI потоците работят добре? Проверете.

Един от членовете на нашия екип докосна приложението за надграждане преди повече от година. Той посочи, че репото, от което аз развих, само по себе си е разклонено репо. Някой друг екип беше работил над това репо, а след това нашият екип работеше върху оригиналното репо от този момент нататък - но членът на моя екип не знае от кой момент нататък. Така че беше малко бъркотия!

Имаме инструмент „Собственост“, който показва правилното репо и ме „излъга“. Така че ситуацията беше такава:

Forkception

Да, това беше Forkception! WTF и FML бяха първите две мисли, които излязоха от устата ми. Трябваше да работя върху репото на живо, но вместо това работех на вилица, която беше застояла. Колко глупаво от мен!

Първа мисъл - трите ми дни работа са изхабени и трябва да започна нова.

Втора мисъл? Нека попитам моя стар приятел Git. Той ми помага от много време.

Аз - „Хей Гит? Изпитвам сериозни проблеми и имам нужда от вашата помощ за разрешаването на този проблем. "

Git - „Хей! Добре, така че първо трябва да започнем от всичко, което е на живо. Създайте нов клон, наречен ъпгрейд, и го насочете към кода на живо. Можете да използвате твърд нулиране на git за това. "

Аз - „Добре, ще го направя.“

В този момент ситуацията изглежда така.

Използване на функциите на Git

Git - „Трябва да знаем какво се промени между разработването и надграждането. Можете ли да изброите файловете, които се различават между вашето надграждане и развитие? Проверете тези файлове поотделно и разберете какви промени са настъпили. "

Аз - „Готино. Виждам три вида промени. Има услуга S1, която трябва да се обадя по различен начин. Има услуга S2, на която трябва да се обадя, използвайки друга крайна точка. Има услуга S3, на която трябва да се обадя, използвайки различни параметри. Виждам също, че файлът package.json в клона на надстройката има някои от пакетите, които вече са надстроени. Така че само няколко пакета трябва да бъдат променени. "

Git - „Страхотно, че сте отделили промените. Сега ми покажете Git дневника на вашия клон за развитие. Надявам се, че сте следвали някои основни практики на Git, например винаги да имате изграждащ се код във всеки ангажимент. Съобщението за ангажиране трябва да изобразява какво сте променили. “

Git лог за развитие клон

Аз - „Да, имам общо четири ангажимента в бранша за развитие. Един от ангажиментите беше да направим проекта изграждащ се. Има едно за всяко от трите разговора за услуги. "

Git - „Перфектно! Изглежда, че сте следвали правилно добрите практики. Нека започнем със стабилизиране на изграждането на проекта чрез актуализиране на package.json. Завържете се към клона за надстройка и направете дубликат на package.json - package-copy.json. Сега, използвайки Git замяна, надстройте / package.json с разработване / package.json и изпълнете разликата между package.json и package-copy.json. Тъй като кодът на живо е променил някои от пакетите и има различни версии, ще трябва да надстроите, като разгледате разликата. "

Изготвяне на проекта

Аз - „Нека да опитам това. Добре, тя се изгражда и работи. "

Git - „Страхотно! Сега, нека работим върху обажданията за услуги. Виждам, че имате един ангажимент за всяка промяна в услуга-обаждане в раздела за развитие. Време е за избор на череши. Изберете от най-малко сложното обслужване до най-сложното обслужване. Избор, сливане и разрешаване на конфликти. Не забравяйте да проверите дали проектът е в състояние на строителство след всяка череша и преди всеки ангажимент. “

Аз - „S1 свърши. S2 свършено. S3 свършено. Благодаря, Git ”

Git - „Не сте добре дошли. Но вие сте сами, които сте помогнали, като следвате практиките на Git ангажиране и не третирате Git като просто съхранение на код. "

Какво направих тук?

Задължителни промени

Направете пауза за момент и помислете дали тази промяна трябва да влезе в този ангажимент. Ангажимент, който казва, че „промяна: крайни точки на обслужване-s1“ и има промени в сервиза-s2, просто би създал объркване.

Не се ангажирайте с половин работа

Често сме чували мантра „ангажирайте се рано, ангажирайте често“. В горния пример можете да имате един ангажимент за различни крайни точки на една и съща услуга. Това се нарича кренвирш.

Въпреки това аз лично разбивам малките си ангажименти, използвайки интерактивен режим на git rebase. Това ми помага да имам една логична промяна, която може да бъде сертифицирана, и помага на доверен ангажимент да прегледа и вашия код. Това е много за предпочитане при мащабни проекти.

Тествайте кода си, преди да се ангажирате

Трябва да мислим за Git като държавна машина и всяка машина трябва да бъде в състояние за изграждане във всяка държава.

Напишете добри съобщения за ангажиране

Това е най-решаващата част. Винаги спирам за момент и си мисля дали ще успея да разбера - след три месеца - вида на промяната в този ангажимент, като само погледна съобщението за ангажиране.

заключение

Успях бързо да разреша бъркотията. Можех да изляза от този момент на WTF и FML, само защото следвах някои добри практики. Те съществуват с причина и са като сол в храната - вие осъзнавате стойността им само когато не се използват.

Грешките ще се случат рано или късно, несъзнателно. Но не забравяйте да следвате съзнателно някои практики около Git.

Привърженик съм на съобщенията за семантични ангажименти на Git, които помагат да се ориентирате в историята на Git. Защото, нека бъдем честни, не можете да очаквате всички да използват едни и същи думи за всяко съобщение за ангажиране. Въпреки това може да се очаква тип съобщение.

Това помага да се гарантира, че след всеки ангажимент, вашият проект може да бъде изграден - което е наистина полезно.

VSCode има болна поддръжка за Git. Става супер лесно да видите конфликтите и да ги разрешите, понякога само с едно щракване. Вижте долния пример

Препратки

  • Git Best Practices
  • Супер страхотна интеграция за управление на версиите в VSCode
  • Git Semantic Comm Messages
  • Съвет за Git : Как да „обедините“ конкретни файлове от друг клон
  • Съвет за Git : Git - git-cherry-pick Documentation
  • Съвет на Git : Git - Документация за нулиране на git

Специални благодарности на моите приятели Саурабх Раджани и Аниш Дхаргалкар, които ми помогнаха с усъвършенстването на съдържанието.