github tutorial developers how use github
Този урок за GitHub обяснява какво е GitHub и как да създадете заявка за хранилище, разклонение и изтегляне. Той включва правила за защита на клоновете и разрешаване на конфликти:
Какво е GitHub?
GitHub е облачна услуга, която помага на разработчиците да съхраняват и управляват своя изходен код, както и да проследяват и контролират всички промени в изходния код.
С прости думи, GitHub е предназначен за разработчици, при които те могат да управляват проекта, да хостват изходния код и да ги преглеждат също. Ще разгледаме всичко това в тази поредица.
Списък с уроци в тази серия GitHub:
Урок # 1: Урок за GitHub за разработчици | Как да използвам GitHub (Този урок)
Урок # 2: Проекти на GitHub, екипи, Fork и Wiki за документиране на проекти
Урок № 3: Разширени Git команди и урок за интеграция на GitHub
Урок № 4: Урок за GITHub REST API - Поддръжка на REST API в GitHub
Урок № 5: Урок за GitHub Desktop - Сътрудничайте с GitHub от вашия работен плот
Урок # 6: Урок за TortoiseGit - Как да използваме TortoiseGit за контрол на версиите
Какво ще научите:
Какво е Git?
Git е система за управление на версиите с отворен код, при която целият изходен код е достъпен на машината на разработчика. Git също е клиентска и разпределена система за контрол на версиите (DVCS), където можете да направите разклоняване и обединяване.
Първи стъпки с GitHub
За да започнем с GitHub, ще изпълним следните стъпки.
- Създайте хранилище за организиране на проекти.
- Създайте клон
- Направете промени във файла и фиксирайте.
- Създайте заявка за изтегляне, за да обедините съдържанието.
- Защитете клон
Във втората част на поредицата ще разгледаме и другите функции на GitHub като Създаване на организация, Екипи, Проблеми, Важни етапи, Форкове, Издания и Уикита.
Създайте хранилище на GitHub
Хранилището на GitHub съдържа артефакти на проекта като изходен код, документи, изображения и др. Ще създадем и използваме демо хранилище, за да изпълним всички горепосочени стъпки.
Влезте в Github.com и Създайте ново хранилище . Щракнете върху Ново бутон.
Добавете долните подробности за репо, както е показано и кликнете върху Създаване на хранилище . Задайте достъп до частен или публичен. По-добре е да го настроите за обществено, тъй като малко функции зависят от този достъп.
Забележка: Потребителят, който създава хранилището, е собственик на хранилището GitHub.
Хранилището се създава с README файл.
Добавяне на сътрудници към хранилището на GitHub
Бихме искали екипът да работи върху това хранилище. За целта ще трябва да поканим сътрудниците да работят по хранилището. За да добавите сътрудници, отидете на главната страница на хранилището и кликнете върху Настройки икона.
Кликнете върху Сътрудници в левия прозорец и добавете сътрудниците, които имат акаунт в Github. Ще бъде изпратена покана и сътрудниците ще трябва да приемат поканата.
Сътрудници се добавят, както е показано по-долу. По-късно, в този урок, ще видим как сътрудниците ще бъдат добавени като рецензент на заявката за изтегляне, създадена за обединяване на кода.
Извършване на Basic C пропусна
Отворете файла README и изпълнете основен ангажимент. Щракнете върху Икона за редактиране за да започнете да модифицирате файла.
Променете файла, добавете коментар и кликнете върху Ангажирайте се .
Файлът е ангажиран (промените са запазени) в хранилището на Github.
Ще се видят няколко операции за създаване на папка и файлове в хранилището.
За да създадете папката и файл в: Щракнете върху Създайте нов файл на ниво хранилище. Въведете името на директорията, последвано от / и името на файла, както е показано по-долу.
Кликнете върху Ангажирайте се на дъното. Папката и файлът се създават, както е показано. По този начин файловете и папките се създават в майстор клон, който е основният клон за интеграция и най-вече там, където могат да се създават версии на софтуера.
Разработчиците обикновено работят по задачата, която им е възложена в отделен клон и обединяват промените в главния клон. Например, клонове могат да бъдат създадени за разработване на функции или разрешаване на грешки или работа по подобрения и т.н. По този начин, чрез създаване на клон работата се изолира, без да се нарушават останалите клонове.
В следващата стъпка можем да разгледаме как могат да бъдат създадени клоновете и да бъдат дефинирани заявки за изтегляне за преглед и обединяване на кода в главния клон.
Преместване на файл
За да преместите файл в друга папка, направете следните стъпки. Например, за да преместите файла rules.txt в папка с документи. Щракнете върху файла.
Щракнете върху иконата, за да редактирате файла.
Добавете пътя документ / преди файла rules.txt . Кликнете върху Ангажиране на промени.
Пътят вече е актуализиран.
Създаване на клон на GitHub
Отидете на главната страница на хранилището и напишете, за да създадете особеност клон, както е показано. Кликнете върху Създайте клон.
Сега сме в особеност клон. Файловете са еднакви. Сега ще направим някои промени във файловете в особеност клон и създайте заявка за изтегляне за преглед на промените и обединяване на кода в майстор клон.
Направете промени във файловете в разклонението на характеристиките.
Отворете Java файла в папката Src и добавете малко код и извършете промяната.
Създайте заявка за изтегляне на GitHub
В предишния раздел създадохме клон особеност и направи някои промени във файл. Промените не са в майстор клон. За това трябва да създадем заявка за изтегляне, чрез която потребителят предлага определени промени, които да бъдат прегледани и обединени в майстор клон.
Създаването на заявка за изтегляне ще покаже разликите между източника и целевия клон и ще бъде необходимо за разрешаване на конфликти, ако има такива.
Кликнете върху Заявка за сравнение и изтегляне на главната страница на хранилището.
Можете да видите, че промените в двата клона могат да бъдат обединени. Кликнете върху Създайте заявка за изтегляне.
Кликнете върху Обединяване на искане за изтегляне и Потвърдете за да завършите сливането.
Промените са успешно обединени в майстор клон. Първата ни заявка за изтегляне е успешно изпълнена.
Назначете рецензенти с искания за изтегляне и преглед на кода
Github има добра характеристика да използва файл CODEOWNERS, в който можем да изберем хората, отговорни за изходния код в хранилището. Собствениците на хранилището могат да създадат този файл и всички потребители, дефинирани във файла, се изискват по подразбиране за преглед по време на създаването на заявка за изтегляне.
За да използвате тази функция, трябва да използвате версията на GitHub Pro или да направите хранилището публично.
В корена на хранилището създайте този файл в следния формат и го фиксирайте.
* @ потребителско име или @orgname или @teamname
* означава преди всичко всички файлове в репото. Можете също така да посочите конкретни разширения като * .java или * .js и др. Потребителите, дефинирани във файла, ще получат заявка за преглед автоматично. С дефинирания файл CODEOWNERS не е необходимо изрично да добавяте рецензенти ръчно и има малко повече гъвкавост при избора кои файлове да бъдат прегледани.
Обратно в особеност клон направете малка промяна в Java файла и създайте заявка за изтегляне. В екрана Pull Request задайте рецензент от дясната страна. Кликнете върху Създайте заявка за изтегляне.
На горния екран можете да видите, че рецензентите могат да бъдат назначени ръчно, но рецензенти са дефинирани във файла CODEOWNERS, който автоматично ще получи заявка за преглед на промените в кода.
Както и да е, засега нека Влизам като рецензент и одобрява промените. Влезте като потребител vniranjan2512, за да одобрите промените.
Има заявка за одобрение / отхвърляне на промените, под Изтеглете заявка.
Щракнете върху Заявка за изтегляне и Добавете отзива си.
Можете да кликнете върху + подпишете и добавете коментари за преглед за реда на кода Добавен / Модифициран / Изтрит, на излизащия екран.
Кликнете върху Започнете преглед.
Кликнете върху Завършете своя преглед. Одобрете, както е показано и Изпратете рецензия .
Като първоначален потребител, който е повдигнал заявка за изтегляне, можете да добавите коментар и да разрешите или затворите разговора.
Заявката за изтегляне на обединяване вече може да бъде изпълнена.
Промените са успешно обединени в майстор клон публикува прегледа и обединяването на заявката за изтегляне.
Така че, за да обобщим на този етап, видяхме, че разработчиците работят върху особеност и след това издигнете искане за изтегляне, за да обедините промените в майстор клон. Горното беше сценарий, при който конфликти не бяха налице. В следващия раздел ще видим начините за ръчно разрешаване на конфликти, ако файловете се променят в множество клонове.
Разрешаване на конфликти
Възможно е едни и същи файлове в множество клонове да бъдат променени. В този случай ще има конфликти и трябва да бъде разрешен чрез повдигната заявка за изтегляне.
Например, направете промени в Java файла и в двата майстор и особеност клони и повдигнете искане за изтегляне.
Показаното съобщение за искане за изтегляне е, че промените не могат да бъдат обединени автоматично. Следователно конфликтите трябва да бъдат разрешени. Продължете да създавате заявка за изтегляне.
След като бъде повдигнато искането за изтегляне, конфликтите ще трябва да бъдат разрешени, като щракнете върху Разрешаване на конфликти бутон.
Премахнете маркировките, които по същество разрешават конфликти ръчно и кликнете върху Маркирайте като разрешено и Ангажиране на сливане.
Окончателният изглед на файла след премахване на маркировките.
Искането за обединяване може да бъде изпълнено. The майстор и особеност клоновете вече ще бъдат идентични.
Все още можете да видите на горния екран, че прегледът е поискан, но не е задължен. В следващия раздел ще видим правилата за защита на клона, при които собственикът на хранилището задължително може да поиска преглед и също така да защити майстор клон от ангажиране директно към него, но само чрез заявка за изтегляне.
Правила за защита на клоновете
В предишните раздели видяхме за Github Pull Requests, както и искания за прегледи, които не са били задължителни или незадължителни. В типичния код за проектни сценарии прегледите са задължителни и част от процеса на разработване.
Нека да видим как да наложим това.
В github.com тази функция може да бъде настроена само за публични хранилища или с помощта на версията Github pro. На главната страница на хранилището отидете на Настройки и кликнете върху Клонове категория вляво.
Кликнете върху Добавяне на правило под Правила за защита на клоновете. Правилото добавя заявки за задължителни прегледи на искания за изтегляне от собствениците на кода преди обединяване за майстор клон.
Това също ще гарантира, че главен клон е защитена и не могат да се правят директни ангажименти за този клон и могат да бъдат извършени само чрез заявки за изтегляне след щателен преглед. Тази настройка се задава от собственика на хранилището.
Наистина страхотна характеристика !!!
Кликнете върху Създайте веднъж направено. За да тествате този сценарий, направете промяна във файл в особеност клон и създайте заявка за изтегляне.
Следващият екран показва, че собствениците на кода задължително изискват преглед.
Публикувайте отзива от собствениците на кода, искането за изтегляне може да бъде обединено.
Като сътрудник на хранилището, ако направите промени в някой от файловете, поради създадените правила на защитените клонове, няма да можете да се ангажирате директно с главния клон, а само чрез заявка за изтегляне след създаване на клон, както е показано По-долу.
Прехвърляне на хранилище към друг потребителски акаунт
Обикновено личното потребителско хранилище има един собственик, а всички останали са сътрудници. Така че, в смисъл, че не можете да имате множество собственици в хранилището на потребителски акаунт. Но собствеността може да бъде прехвърлена към друг потребителски акаунт. Когато приключи, собственикът на оригиналното хранилище автоматично се превръща в сътрудници в новото хранилище на потребителски акаунт.
След това новият собственик може да започне да управлява артефактите, проблемите, исканията за изтегляне, проектите, изданията и настройките.
Обикновено, когато команди като „git clone“ или „git push“ се изпълняват в локалното хранилище, командите ще пренасочват към новото хранилище. Но когато стартирате командата ‘git remote -v’, тя все пак ще показва оригиналния URL адрес на хранилището. За да се избегне объркване да се премине към новия отдалечен URL адрес, прехвърлянето на хранилището се използва с командата ‘git remote set-url’.
За да прехвърлите хранилище, отидете в раздела Настройки на хранилището и под Опции? Щракнете върху зона за опасност Прехвърляне
Въведете името на хранилището и новия потребителски акаунт, на който собствеността трябва да бъде прехвърлена.
Кликнете върху Разбирам, прехвърлете това хранилище
Трябва да видите съобщение, че хранилището е прехвърлено на новия собственик.
Ще бъде изпратено имейл до собственика на оригиналното хранилище, за да одобри прехвърлянето. След като трансферът бъде одобрен, хранилището ще бъде прехвърлено на новия собственик и собственикът на оригиналното хранилище ще бъде добавен като сътрудник.
Сега задайте новия URL адрес на хранилището в машината, където е клонирано старото хранилище. Следните команди трябва да бъдат зададени във всички машини, където е клонирано старото хранилище.
Всички искания, проблеми, wiki ще бъдат прехвърлени. Заданията за издаване ще останат непокътнати.
Някои полезни Git команди
Има някои от основните Git команди, които трябва да бъдат конфигурирани първоначално на вашата локална машина, след като клиентът Git бъде инсталиран на вашата Linux или Windows машина. Разработчиците работят локално, без връзка с хранилището на GitHub, върху пълното копие на изходния код, наличен на GitHub, и се синхронизират с него.
Първо, задайте вашето потребителско име и имейл адрес, за да сте сигурни, че всички ангажименти, които правите, използват тази информация.
git config –global user.name “UserName”
git config –global user.email “myemail@myemail.com”
Когато трябва да добавите съобщение по време на фиксиране, можете също да конфигурирате редактора, необходим за същото.
редактор на атоми срещу код на визуално студио
git config –global core.editor notepad
Получете списък с всички зададени стойности на конфигурацията.
git config –list
Понякога организациите имат прокси сървъри за свързване към интернет. В този случай ще трябва да посочите прокси сървър и номер на порт, за да получите достъп до всички хранилища на GitHub.
git config –global http.proxyhttp: // Потребителско име: Парола @ proxyserver: порт
Клонирайте или направете локално копие на хранилището. Вземете URL адреса на клонинга на хранилището в GitHub и изпълнете командата git.
Заключение
В този урок видяхме как разработчикът може да започне да работи върху GitHub, направо от Създаване на GitHub хранилище, клон, искане за изтегляне, защита на клон и някои основни Git команди.
В нашия предстоящ урок ще видим другите функции на GitHub главно за това как да създавате организации, екипи, да разклонявате хранилище, да създавате проблеми, етапи и да се свързвате с искания за изтегляне, wiki и техните приложения и няколко други разширени Git команди, които ще бъдат полезни на разработчиците.
Препоръчително четене
- Урок за отражение на Java с примери
- Git срещу GitHub: Разгледайте разликите с примери
- Урок за Python DateTime с примери
- Интеграция на селен с GitHub с помощта на Eclipse
- Кратко ръководство за SoapUI за съхраняване на данни за заявки и отговори във файл - Урок SoapUI # 15
- Урок за Bugzilla: Ръчен урок за инструмент за управление на дефекти
- 20+ MongoDB урок за начинаещи: Безплатен курс на MongoDB
- MongoDB Урок за оцветяване с пример