Как да не създавате локални файлове с Git част 2

Извършва, натиска и дърпа

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

Обхват на тази статия

Комитетите са хлябът и маслото на Git и Github, те организират целия ви код, трябва да ги направите лесни за разбиране за други разработчици, за да могат да видят какво сте променили и как напредват проектът и вашият код.
Част 2 ще се съсредоточи върху ангажиментите на етикета и как да се управляват тласъци и дърпания.

Инструменти

Както преди, ние просто ще използваме Git клиента и Visual Studio Code за страхотната интеграция на Git.

Основи

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

Добрите разработчици използват поръчки след публикуването им, за да разберат как са направени нещата и кои файлове са били променени. Мислете за приложението си като за наистина добра книга.

Главите са еквивалент на комити (вид, а не буквално), ако искате да знаете къде в книгата Алис попада в заешката дупка, ще откриете, че това е така в глава, наречена „Надолу на зайчето-дупка“, вашите ангажименти трябва да следвайте същите правила.

Лабиринтът от сложни и неописателни ангажименти, с които никой не иска да се занимава.

Какво трябва да съдържа един добър ангажимент

Най-важното нещо при поръчките е какво съдържат. Колкото и просто да изглежда това, на разработчиците често е трудно да следват.

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

Всеки ангажимент има тема, трябва да запомните, че комитите свикват много. За да улесните работата си и всички останали, трябва да ги направите малки само с „един“ вид промяна. Например, смяната на React.PropTypes (react <15.5) на тип тип prop (реагиране ≥15.5) за 5 различни файла може да бъде само един ангажимент, но ако искате да промените Redux действие, това е друг ангажимент, не смесвайте различни неща ,

С този метод ще имате много повече ангажименти и всички те ще имат смисъл, можете да се похвалите с приноса си с git, докато сте хвалени като добър дявол, не е ли това страхотно?

Задължително заглавие

$ git commit -m "Поправете чувствителността на регистъра за въвеждане на имейл"

Използвайте първата буква, не много за обяснение, Граматика 101.

Под 72 знака и около 50 средно не искате вашето съобщение за ангажиране да бъде разбито на две части (известните три точки). Ето как се представят добрите ангажименти.

Не правете това!

Дръжте го кратко и ясно, това означава, че текстът на вашия ангажимент трябва да бъде кратко обяснение на това, което прави, ангажиментът по-горе не е нито ясен, нито кратък, той съдържа корекция за маршрут с /: потребителско име, което се оценява преди / изход, това означава, че тя винаги считаше изходът за потребителско име и се опитваше да извлече профил от базата данни, наречена logout. Прост въпрос за приоритет на маршрутите. Какво би било по-добро име за този ангажимент?

$ git commit -m "Оправяне на приоритета на маршрутите"

Кратко и направо дотам, ако искате повече информация за това, което прави ангажимента, можете да отворите ангажимента и да проверите промените в кода, че е добър навик да имате, докато растете като програмист.

Но искам да бъда по-конкретен от този в ангажимента си, как мога да го направя в 50 часа?

Ангажирайте орган

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

За щастие има лесен и бърз начин да пишете съобщения на тялото от конзолата, без да използвате vim, който всички обичат.

$ git commit -m "Моето заглавие на ангажимент" -m "Моето съобщение на тялото на ангажимента"

Ангажирайте с VSCode

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

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

Просто щракнете върху V и сте готови.

Полезно е да сте фокусирани върху редактора, докато вършите голяма работа, тъй като можете да продължите да променяте кода си, докато го ангажирате, докато напредвате.

Как да натиснете страхотните си ангажименти, без да унищожавате всичко

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

Сега имаме перфектни ангажименти в нашите перфектни клонове, как да прокараме цялата тази страховитост?

Да зададем някои навици

След като приключите работата си с кода, винаги трябва да актуализирате клона си от основния клон, на който е бил базиран. Обикновено рутината ми е следната:

// започваме от fix fix / my-branch
$ git checkout развитие
$ git издърпване
$ git checkout fix / my-branch
$ git сливане развитие

Нека обясним подробно какво се случва тук.

На първо място, git pull прави същото като git fetch + git merge и това идва с по-малко контрол и повече странични ефекти, тук няма да навлизаме в подробности, предпочитам да използвам и двата метода и ето моите разсъждения.

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

Тъй като не работите в раздела за развитие, винаги е чисто. Можем да използваме git pull без да се притесняваме за страничните ефекти. Постоянното актуализиране на този клон ще бъде полезно за намаляване на броя на конфликтите за сливане в новите клонове, които създавате.

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

Ако сливането върви без проблеми

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

След като обедините заявката си и следвате стандартния етикет от там, сте готови, дайте си потупване по гърба!

Ако сливането среща конфликти

Знам, знам, че се случва непрекъснато.

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

По дяволите, защо?

Както можете да видите, конзолата вече ни помага, като ни дава името на файла, където са възникнали конфликти, нека да отворим този файл.

Visual Studio е полезен както винаги.

Това виждаме във Visual Studio отваряне на „повредения“ файл, нека да започне от лявата странична лента.

(C) ← в лилаво ни казва кои файлове имат конфликти (можем да видим това и на конзолата, но тук е по-лесно да се визуализира).

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

Можете да изберете кой да приемете, като използвате удобното меню за самия конфликт или ръчно изтриете стария код и запазите новия.

След като разрешите всички конфликти, ангажирате резултата. Ако искате да го тествате отново, просто изпълнете горните команди, за да изтеглите и слеете от раздела за развитие отново и след като сте сигурни, че няма повече конфликти, просто натиснете клона и изтеглете заявка срещу клон за развитие, voilà сте готови!

Заключение или TLDR

Правете добри ангажименти, хвалете се с историята на ангажиментите си, бъдете разработчик, който всеки обича да преглежда, не ставайте жертва на конфликти, пийте поне 6 чаши вода всеки ден и ходете на разходка всеки път.

Можете да намерите част 3 от тази серия тук и ако не сте прочели първата, можете да я прочетете тук.