msb-public
/
Web-Dev-For-Beginners
mirror of https://github.com/microsoft/Web-Dev-For-Beginners.git
1
0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'softchris-patch-4'
${ noResults }
Web-Dev-For-Beginners/translations/bg/1-getting-started-lessons/2-github-basics
History
Lee Stott 2daab5271b
Update Quiz Link 		3 weeks ago
..
README.md Update Quiz Link 3 weeks ago

README.md
Escape

Въведение в GitHub

Този урок обхваща основите на GitHub, платформа за хостване и управление на промените в кода ви.

Въведение в GitHub

Скетч от Tomomi Imura

Предварителен тест

Предварителен тест

Въведение

В този урок ще разгледаме:

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

Предварителни изисквания

Преди да започнете, трябва да проверите дали Git е инсталиран. В терминала напишете: git --version

Ако Git не е инсталиран, изтеглете Git. След това настройте локалния си Git профил в терминала:

  • git config --global user.name "вашето-име"
  • git config --global user.email "вашият-имейл"

За да проверите дали Git вече е конфигуриран, можете да напишете: git config --list

Ще ви е необходим и акаунт в GitHub, редактор за код (като Visual Studio Code) и трябва да отворите терминала си (или командния ред).

Отидете на github.com и създайте акаунт, ако все още нямате такъв, или влезте и попълнете профила си.

✅ GitHub не е единственото хранилище за код в света; има и други, но GitHub е най-известното.

Подготовка

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

Управление на кода

Да кажем, че имате локална папка с проект за код и искате да започнете да проследявате напредъка си с помощта на git - системата за контрол на версиите. Някои хора сравняват използването на git с писане на любовно писмо до бъдещото си аз. Четейки съобщенията за комит дни, седмици или месеци по-късно, ще можете да си припомните защо сте взели дадено решение или да "върнете" промяна - стига да пишете добри "съобщения за комит".

Задача: Създайте хранилище и комитнете код

Вижте видеото

Видео за основите на Git и GitHub

  1. Създайте хранилище в GitHub. На GitHub.com, в раздела за хранилища или от навигационната лента горе вдясно, намерете бутона new repo.

    1. Дайте име на вашето хранилище (папка).
    2. Изберете create repository.

  2. Навигирайте до работната си папка. В терминала си преминете към папката (известна още като директория), която искате да започнете да проследявате. Напишете:

    cd [name of your folder]

  3. Инициализирайте git хранилище. В проекта си напишете:

    git init

  4. Проверете статуса. За да проверите статуса на вашето хранилище, напишете:

    git status

    Резултатът може да изглежда така:

    Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

     modified:   file.txt
     modified:   file2.txt

    Обикновено командата git status ви казва неща като кои файлове са готови за записване в хранилището или имат промени, които може да искате да запазите.

  5. Добавете всички файлове за проследяване Това се нарича също "стейджване" на файлове/ добавяне на файлове към зоната за стейджинг.

    git add .

    Аргументът git add плюс . показва, че всички ваши файлове и промени са готови за проследяване.

  6. Добавете избрани файлове за проследяване

    git add [file or folder name]

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

  7. Премахнете всички файлове от стейджинг

    git reset

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

  8. Премахнете конкретен файл от стейджинг

    git reset [file or folder name]

    Тази команда ни помага да премахнем само конкретен файл от зоната за стейджинг, който не искаме да включим в следващия комит.

  9. Запазване на работата ви. На този етап сте добавили файловете към така наречената зона за стейджинг. Място, където Git проследява вашите файлове. За да направите промяната постоянна, трябва да комитнете файловете. За да направите това, създайте комит с командата git commit. Комит представлява точка за запазване в историята на вашето хранилище. Напишете следното, за да създадете комит:

    git commit -m "first commit"

    Това комитва всички ваши файлове, добавяйки съобщението "first commit". За бъдещи съобщения за комит ще искате да бъдете по-описателни, за да предадете какъв тип промяна сте направили.

  10. Свържете локалното си Git хранилище с GitHub. Git хранилище е полезно на вашия компютър, но в даден момент ще искате да имате резервно копие на вашите файлове някъде и също така да поканите други хора да работят с вас върху вашето хранилище. Едно такова страхотно място за това е GitHub. Помнете, че вече създадохме хранилище в GitHub, така че единственото, което трябва да направим, е да свържем локалното Git хранилище с GitHub. Командата git remote add ще направи точно това. Напишете следната команда:

    Забележка: преди да напишете командата, отидете на страницата на вашето GitHub хранилище, за да намерите URL адреса на хранилището. Ще го използвате в командата по-долу. Заменете https://github.com/username/repository_name.git с вашия GitHub URL.

    git remote add origin https://github.com/username/repository_name.git

    Това създава remote, или връзка, наречена "origin", сочеща към GitHub хранилището, което създадохте по-рано.

  11. Изпратете локалните файлове в GitHub. Досега сте създали връзка между локалното хранилище и GitHub хранилището. Нека изпратим тези файлове в GitHub с командата git push, както следва:

    Забележка: името на вашия branch може да е различно по подразбиране от main.

    git push -u origin main

    Това изпраща вашите комити в "main" branch в GitHub.

  12. Добавяне на още промени. Ако искате да продължите да правите промени и да ги изпращате в GitHub, ще трябва да използвате следните три команди:

    git add .
git commit -m "type your commit message here"
git push

    Съвет: Може също да искате да използвате файл .gitignore, за да предотвратите появата на файлове, които не искате да проследявате, в GitHub - например файл с бележки, който съхранявате в същата папка, но няма място в публично хранилище. Можете да намерите шаблони за .gitignore файлове на .gitignore templates.

Съобщения за комит

Добро заглавие на съобщение за Git комит завършва следното изречение: Ако бъде приложено, този комит ще <вашето заглавие тук>

За заглавието използвайте императивно, сегашно време: "променя" вместо "променено" или "промени". Както в заглавието, така и в тялото (по избор) използвайте императивно, сегашно време. Тялото трябва да включва мотивацията за промяната и да я сравни с предишното поведение. Обяснявате защо, а не как.

✅ Отделете няколко минути, за да разгледате GitHub. Можете ли да намерите наистина добро съобщение за комит? Можете ли да намерите наистина минимално? Каква информация смятате, че е най-важна и полезна за предаване в съобщение за комит?

Задача: Сътрудничество

Основната причина за качването на неща в GitHub беше да се направи възможно сътрудничеството с други разработчици.

Работа по проекти с други хора

Вижте видеото

Видео за основите на Git и GitHub

Във вашето хранилище навигирайте до Insights > Community, за да видите как вашият проект се сравнява с препоръчаните стандарти за общността.

Ето някои неща, които могат да подобрят вашето GitHub хранилище:

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

✅ README файловете, въпреки че отнемат време за подготовка, често се пренебрегват от заети поддържащи. Можете ли да намерите пример за особено описателен README? Забележка: има някои инструменти за създаване на добри README файлове, които може да искате да опитате.

Задача: Слейте код

Документите за допринасяне помагат на хората да допринасят за проекта. Те обясняват какви типове допринасяния търсите и как работи процесът. Сътрудниците ще трябва да преминат през серия от стъпки, за да могат да допринесат за вашето хранилище в GitHub:

  1. Форкване на вашето хранилище. Вероятно ще искате хората да форкнат вашия проект. Форкването означава създаване на копие на вашето хранилище в техния GitHub профил.
  2. Клониране. Оттам те ще клонират проекта на своя локален компютър.
  3. Създаване на branch. Ще искате да ги помолите да създадат branch за своята работа.
  4. Фокусиране на промяната върху една област. Помолете сътрудниците да концентрират своите допринасяния върху едно нещо наведнъж - така шансовете да можете да слеете тяхната работа са по-големи. Представете си, че те пишат поправка на бъг, добавят нова функция и актуализират няколко теста - какво ако искате или можете да приложите само 2 от 3, или 1 от 3 промени?

✅ Представете си ситуация, в която branch-овете са особено критични за писането и доставянето на добър код. Какви случаи на употреба можете да си представите?

Забележка: бъдете промяната, която искате да видите в света, и създавайте branch-ове за вашата собствена работа също. Всички комити, които правите, ще бъдат направени в branch-а, на който сте "чекнати". Използвайте git status, за да видите кой branch е това.

Нека преминем през работния процес на сътрудник. Приемете, че сътрудникът вече е форкнал и клонирал хранилището, така че има готово Git хранилище за работа на своя локален компютър:

  1. Създаване на branch. Използвайте командата git branch, за да създадете branch, който ще съдържа промените, които искат да допринесат:

    git branch [branch-name]

  2. Превключване към работния branch. Превключете към посочения branch и актуализирайте работната директория с git switch:

    git switch [branch-name]

  3. Работа. На този етап искате да добавите вашите промени. Не забравяйте да кажете на Git за тях със следните команди:

    git add .
git commit -m "my changes"

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

  4. Сливане на вашата работа с main branch. В даден момент сте готови с работата си и искате да я слеете с тази на main branch. Междувременно main branch може да се е променил, така че се уверете, че първо го актуализирате до последната версия със следните команди:

    git switch main
git pull

    На този етап искате да се уверите, че всички конфликти, ситуации, в които Git не може лесно да комбинира промените, се случват във вашия работен branch. Затова изпълнете следните команди:

    git switch [branch_name]
git merge main

    Това ще доведе всички промени от main във вашия branch и се надяваме, че можете просто да продължите. Ако не, VS Code ще ви покаже къде Git е объркан и просто променяте засегнатите файлове, за да посочите кое съдържание е най-точно.

  5. Изпращане на вашата работа в GitHub. Изпращането на вашата работа в GitHub означава две неща. Пушване на вашия branch към вашето хранилище и след това отваряне на PR (Pull Request).

    git push --set-upstream origin [branch-name]

    Горната команда създава branch във вашето форкнато хранилище.

  6. Отваряне на PR. След това искате да отворите PR. Това става, като навигирате до форкнатото хранилище в GitHub. Ще видите индикация в GitHub, където се пита дали искате да създадете нов PR, кликвате върху това и сте отведени до интерфейс, където можете да промените заглавието на съобщението за комит, да му дадете по-подходящо описание. Сега поддържащият на хранилището, което сте форкнали, ще види този PR и да се надяваме ще оцени и слее вашия PR. Вече сте сътрудник, ура :)

  7. Почистване. Счита се за добра практика да почистите след успешно сливане на PR. Искате да почистите както локалния си branch, така и branch-а, който сте пушнали в GitHub. Първо, нека го из Уверете се, че отидете на страницата на GitHub за форкнатото хранилище и премахнете отдалечения клон, който току-що сте качили.

Pull request изглежда като странен термин, защото всъщност искате да качите вашите промени в проекта. Но поддръжникът (собственикът на проекта) или основният екип трябва да разгледат вашите промени, преди да ги обединят с "главния" клон на проекта, така че всъщност искате решение за промяна от поддръжника.

Pull request е мястото, където се сравняват и обсъждат разликите, въведени в даден клон, с ревюта, коментари, интегрирани тестове и други. Един добър pull request следва приблизително същите правила като съобщение за commit. Можете да добавите препратка към проблем в тракера за проблеми, например когато вашата работа решава даден проблем. Това се прави с #, последвано от номера на проблема. Например #97.

🤞Стискайте палци всички проверки да преминат успешно и собствениците на проекта да обединят вашите промени в проекта🤞

Актуализирайте текущия локален работен клон с всички нови commit-и от съответния отдалечен клон в GitHub:

git pull

Как да допринесете за отворен код

Първо, нека намерим хранилище (или repo) в GitHub, което ви интересува и към което искате да допринесете с промяна. Ще искате да копирате съдържанието му на вашата машина.

✅ Добър начин да намерите хранилища, подходящи за начинаещи, е да търсите по етикета 'good-first-issue'.

Копиране на хранилище локално

Има няколко начина за копиране на код. Един от тях е да "клонирате" съдържанието на хранилището, използвайки HTTPS, SSH или GitHub CLI (Command Line Interface).

Отворете вашия терминал и клонирайте хранилището по следния начин: git clone https://github.com/ProjectURL

За да работите по проекта, преминете към правилната папка: cd ProjectURL

Можете също така да отворите целия проект, използвайки Codespaces, вградения редактор на код / облачна среда за разработка на GitHub, или GitHub Desktop.

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

Няколко интересни неща за GitHub

Можете да добавите звезда, да наблюдавате и/или да "форкнете" всяко публично хранилище в GitHub. Можете да намерите вашите хранилища със звезда в падащото меню в горния десен ъгъл. Това е като да запазите отметка, но за код.

Проектите имат тракер за проблеми, най-често в раздела "Issues" в GitHub, освен ако не е посочено друго, където хората обсъждат проблеми, свързани с проекта. А разделът Pull Requests е мястото, където хората обсъждат и преглеждат промени, които са в процес на работа.

Проектите може също да имат дискусии във форуми, пощенски списъци или чат канали като Slack, Discord или IRC.

✅ Разгледайте новото си хранилище в GitHub и опитайте няколко неща, като редактиране на настройки, добавяне на информация към вашето хранилище и създаване на проект (като Канбан дъска). Има много неща, които можете да направите!

🚀 Предизвикателство

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

Тест след лекцията

Тест след лекцията

Преглед и самостоятелно обучение

Прочетете повече за допринасянето към софтуер с отворен код.

Git cheatsheet.

Практикувайте, практикувайте, практикувайте. GitHub предлага страхотни учебни пътеки чрез skills.github.com:

Ще намерите и по-напреднали курсове.

Задача

Завършете курса "Първата седмица в GitHub"

Отказ от отговорност:
Този документ е преведен с помощта на AI услуга за превод Co-op Translator. Въпреки че се стремим към точност, моля, имайте предвид, че автоматичните преводи може да съдържат грешки или неточности. Оригиналният документ на неговия изходен език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален превод от човек. Ние не носим отговорност за каквито и да е недоразумения или погрешни интерпретации, произтичащи от използването на този превод.