Първо, основната цел на ангажимента е да се въведе атомна промяна.

Атомните промени съдържат само една функция, рефакторинг, корекция и т.н.

Добрият ангажимент позволява да се оценява една промяна наведнъж и съдържа само/всички необходими промени.

Лошите ангажименти се случват поради лош работен процес.

Вашият работен процес рядко е отражение на това, което трябва да се съдържа в един добър ангажимент, т.е.

9 пъти от 10, ако се ангажирате с помощта на git commit -a, вие го правите 💩 ангажимент.

Работният процес трябва да бъде:

  • завършете разработването на функцията и я тествайте
  • помислете отново за всички промени, които трябваше да направите, и как бихте искали да ги представите
  • етап избрани редове/rebase за създаване на ангажименти, които ги въвеждат в логически части/ред

Ако все още не сте го направили, моля, научете как да изпълнявате интерактивна постановка.

http://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging

Освен git, има много инструменти, които предоставят GUI и го правят супер прост. Любимата ми е Кулата.

Ако направите горното, тогава вашите PR ангажименти трябва да гласят нещо подобно на:

* feat: add claimUsername test helper
* test: ensure that username is at least 5 characters long
* test: ensure that in-use username cannot be claimed
* refactor: have registerNewTestUser use claimUsername
* refactor: have completeUserOnboarding use claimUsername

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

Също така, само като четете ангажиментите, получавате добра умствена карта на всички промени.

Освен това помага за по-бързото забелязване на потенциално критични промени.

  • може ли добавянето на функция да наруши кода? не
  • може ли добавянето на тест да развали кода? не
  • може ли преработването на съществуващ код, за да се използва нова функция, да разбие кода? може би

Също така е супер важно вашият код да работи след всеки комит.

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

Ако не наложите горното, тогава трябва да наложите скуошинг ангажименти при сливане на PR.

Професионален съвет: Ако провеждате интервю за инженерна работа, помолете интервюиращия да сподели последния дневник на записите на кодовата база, към която ще допринасяте.

git log --pretty=oneline --abbrev-commit

Ще ви разкаже много за тяхната инженерна култура.

За разлика от това, лошият дневник на ангажиментите е резултат от „комитиране, докато вървите“ и изглежда по-скоро като:

* test: add helper
* refactor: use helper
* fix: add missing configuration
* fix: inline editing
* fix: failing tests
* fix: revert earlier fix
* refactor: use helper

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

Обърнете внимание, че не говорих за съдържание/форматиране на самите съобщения за ангажименти. Каква конвенция приемате е много по-малко важно от това просто да имате атомни ангажименти. Всъщност страхотните съобщения за ангажименти са страничен продукт/индикация за атомарни ангажименти и обратното.

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

Не е необходимо всеки ангажимент/PR да бъде перфектен, но това показва кой полага усилия и ако другите видят, че полагате усилия, те ще го направят. 🕊

За още страхотно мое съдържание ме последвайте в Twitter https://twitter.com/kuizinas/status/1541496585275727875