Skip to content

Latest commit

 

History

History
131 lines (104 loc) · 9.19 KB

GIT_INSTRUCTIONS.md

File metadata and controls

131 lines (104 loc) · 9.19 KB

Инструкции за ползване на git за нуждите на курса

Не push-вайте в main - това ще го правя само аз. Вашите промени минават през pull request-и.

Ресурси за git

"Официална" git книжка

Препоръчвам (в изброения ред) главите 1, 2, 3, 10 и потенциално после и 8.1, 7.1, 7.2, 7.3, 7.6, 7.7, 7.10, 8.2.

https://ohshitgit.com/ - "обърках нещо, помощ 🥺"

Предварителни стъпки

Инсталирайте git:

Препоръчвам също така и да си направите ssh ключ и да ползвате "ssh клониране"/менежиране на отдалеченото хранилище (става най-лесно, използвайки споменатото по-долу ssh клониране).

Инструкции за генериране на ключ

Инструкции за слагане на ключа в GitHub

Клонирайте вашето хранилище:

# ssh клониране
> git clone [email protected]:googleson78/fp-lab-2023-24-tasks-<вашият-github-потребител>.git
# HTTPS клониране
> git clone https://github.com/googleson78/fp-lab-2023-24-tasks-<вашият-github-потребител>.git

tl;dr

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

# зачистваме всички сегашни неcommit-нати промени
> git restore .
# отиваме на main
> git switch main
# взимаме каквито промени е вкарал Георги в main,
# внимавайки да не сме сложили нещо, което го няма в отдалеченото хранилище
> git pull --ff-only
# правим си нов клон за новото домашно, веднага отивайки на него
> git switch --create <каквото име искате, обвързано с домашното например>
...програмиране...
# решаваме че сме направили достатъчно промени за commit, например решили сме една задача
git add <файловете обвързани с нашите промени>
# правим commit, опитваме се да пишем хубаво съобщение
git commit
# бутаме си промените от сегашния клон в отдалеченото хранилище
# -u origin HEAD частта обвързва сегашния клон с "еквивалента" му в отдалеченото хранилище
# това е нужно само първият път в който push-ваме, след това git push e достатъчно
git push -u origin HEAD
...повтаряме процеса add-commit-push докато не решим задачите...

В някакъв момент, когато имате поне нещо push-нато, или когато се чувствате готови да ви гледам задачите, отивате в GitHub и правите pull request от клона ви с решението на домашното към main.

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

Най-често тези коментари са

  • "яко, защото X"
  • "това е ок и ще ти дам точки за него, но може и по-добре, защото X"
  • "това не е правилно и няма да получиш точки за него, защото X"

Когато приключи срокът за домашното може да спрете да бутате нови неща по pull request-а (а и няма и да гледам неща бутнати след крайния срок), като в някакъв бъдещ момент, след като проверя домашните, ще слея pull request-а в main.

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

FAQ

Направих си клон вече за домашното, но има нови неща в main. Как да си ги "взема"?

Имате две опции - можете или да merge-нете main във вашия клон, или да rebase-нете вашия върху main.

И двете стават доста подобно:

# първо ще трябва да си вземем локално въпросните промени от main
git fetch
# може в този момент и да си синхронизираме локалният ни main с отдалеченият такъв
git switch main
git pull
# връщаме се на клона ни за домашното
git switch <името на клона на домашното ни>

# допускаме че вече сме на вашия клон за домашното
# наблягам че ако не сме си взели локално промените в main,
# тези команди ще трябва да изпълним с origin/main, вместо с main
# merge вариантът, създава се merge commit
git merge main
# rebase вариантът, ще трябва push --force след това,
# защото сме пренапислаи историята на клона ни
git rebase main

Разликите между двете са описани надълго и нашироко из интернета. Ако имате конкретен въпрос по темата, е напълно ок да ме питате.

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

# оригинален текст
f :: Int -> Int
# при вас
f :: Integer -> Integer
# в main
f :: Char -> Char

В този слуачай, git ще ви покаже и двата варианта (заедно с текстови индикатор кои промени откъде идват) и ще ви помоли да редактирате текста, оставяйки оставите вариант на кода, който ви устройва (както и да махнете текстовите индикатори за промени). Например може да решите че или искате да разкарате вашата версия (оставяйки само f :: Char -> Char), или искате да смесите двете версии (f :: Char -> Integer).

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

За конфликтите, препоръчвам (по принцип, не само за курса) да си пуснете т.нар. three-way diff настройка:

git config --global merge.conflictstyle diff3

която казва на git да показва и оригиналната версия, а не само "вашата" и "другата".

git restore/git switch не работят!

Обновете си git до 2.23 или по-нов.

Алтернативно, можете да замените:

  • git restore <files> -> git checkout <files>
  • git switch <branch> -> git checkout <branch>
  • git switch --create <branch> -> git checkout -b <branch>

Какво са git restore/git switch?

Тъй като git checkout прави много неща, са решили да отделят "менежиране на файлове" от "сменяне на клонове" частите една от друга. За повече информация вижте тук