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

Клонове и работен процес

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

Работата с екип изисква малко повече от „git добавяне“ и „git ангажиране“, така че нека започнем да изследваме красивия свят на Git.

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

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

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

Част 1 ще се фокусира върху това как трябва да управлявате работния си процес с Git, за да избегнете най-често срещаните проблеми.

Инструменти

Не се нуждаете от фантастични инструменти или команди, за да използвате Git ефективно, за тази статия и тези, които следвате, аз просто ще използвам самия Git и редактора на кода по избор (с интеграция на Git).

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

Visual Studio Code или всеки друг редактор с интеграция с Git, той ще направи живота ви толкова по-лесен.

Основи

Първо да започнем с основите на етикета на Github (можем да се адаптираме и да надграждаме върху тях, те не са поставени в камък, а добра отправна точка).

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

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

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

Дъвчете тази пура, Клинт.

Какво трябва да правите, когато искате да работите върху нещо

$ git clone git@github.com: Kornil / simple-react-app.git

Това е началото, правите го веднъж и никога повече.

От тук нататък ще работим по клонове. По подразбиране ще бъдете в основния клон. ВЗЕМЕТЕ ОТ ТОВА.

$ git checkout развитие

Това е по-добре, нали? Сега сте в клона за развитие, това е клонът, към който винаги трябва да се позовавате, тя е любовта на живота ви и ще се отнасяте към нея с уважението, което тя заслужава.

Как?

$ git checkout -b myNewBranch

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

Изпълнявайки „git клон“, ще видите, че всъщност сте вътре в този нов клон. Това е само на вашата машина, кажете „Здравей!“ На новия ви работещ клон.

За визуалните учащи.

Именуване на клони

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

myNewBranch не обяснява нищо и не решава проблемите ни, имаме нужда от конвенция за именуване:

"поправяне / фиксирани всички тапа"
"Функция / гигант-патица-модален"
"Преструктуриране на / ADD-проп-видове"
"Стил / всичко-е-черно"

Вид / късо описание

Видове

Ще дефинираме 4 основни типа клонове: бъг, функция, рефактор и стил: съответно за грешки, нови функции, префакторинг на кодове и неща за дизайн / css, след като типът идва името, той трябва да посочи отгоре на типа клон.

$ git checkout -b стил / розови бутони

Това казва на вас и вашите приятели всичко, което ще кодирате в този нов клон.

F-! Забравих да създам нов клон, преди да започна да се забърквам и все още съм в развитие!

Не се тревожи Лео, можем да го разрешим. Има два начина, които можем да използваме, за да се възстановим от това бедствие:

Първо, ако не сте извършили нищо:

$ git скривалище

Запазва всички ваши промени (нито ангажирани, нито поетапно) някъде и ги премахва от вашия клон.

Сега вашият клон за развитие е чист, така че просто стартирайте

$ git checkout -b функция / каучук-патица-cta
$ git скривалище поп

Ще създадете нов местен клон и ще поставите тук всичките си промени. Не забравяйте, че скривалището е като поставяне на копие, изключително полезно, но в същото време окончателно, ако „приберете скривалище“ още веднъж, можете да се сбогувате с първия си скривалище. ПОЧИВАЙ В МИР.

Втори начин, Ако вече сте извършили промените:

$ git push origin origin: fix / your-smart-fix

Запишете кода си в ново материализирания клон / your-smart-fix клон на вашия проект Github (ако приемем, че работите върху клона за разработка).

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

$ git чек майстор
$ git клон -D развитие
$ git извличане
$ git checkout // // незадължително, само за да видите, че е чисто
$ git checkout fix / your-smart-fix

Нека преодолеем това бързо:

Първо, преминете към главен клон (вашият безопасен клон), след което изтриваме разклонението, извличаме всеки клон от Github (не се притеснявайте, че няма да ги видите с „git клон“) и отново преминете към развитие. Сега можете да стартирате "git status", за да проверите дали развитието е чисто и от това можете да се върнете към вашия работен клон, достатъчно лесно нали?

Използване на Visual Studio, за да изглеждате умно

Visual Studio е повече от редактор, като банан за маймуна, не бива да живеете без него. Нека да видим какво може да направи за нас.

Скучно ли сте да използвате „git add.“? Искате ли да задействате само 3 файла, защото всичко останало е бъркотия и знаете, че ще се ударите, ако се опитате да отровите хранилището на Github с тази мръсотия? Тук идва VSCode!

Вижте тази каша!

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

Но първо, какви са тези букви вдясно?

(M) ← файлът е променен след последния ангажимент.

(D) ← файлът е изтрит след последния ангажимент.

(U) ← това е съвсем нов файл.

Това помага ли? Малко, но все пак, нека да работим! Задръж на файла, който искам да добавя, показва още 2 икони, нека видим какво правят.

Първата е стрелка, тя връща всички ваши промени до последния ангажимент (любимия ми бутон!).

Второто е символ плюс, щракването върху него е като пускане на „git add .gitignore“, той добавя нашите файлове за следващия ангажимент, можем да използваме тази удобна функция, за да добавим само файловете, които искаме за този ангажимент, и да запазим останалото там.

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

Сега има 2 различни реда, обичайният наречен промени и нов за файла, който добавихме, наречен поетапни промени. Етапно означава файл, който ще бъде ангажиран със следващия „git commit“, но както виждате, имаме нова икона, знак минус! Това също може да бъде много полезно, тъй като избягва промените ни, връщайки файла обратно към промените, при които можем да решим дали просто играем етап / неустойчивост или искаме да възстановим предишния ангажимент.

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

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

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