• На 3 декември, вместо лекция, в зала 200
• Ще бъдете разделени на две групи
• Четни факултетни номера са от 19:00, нечетни - от 20:00
• Ако някой не може в дадения час, да ни пише, за да се уговорим друго

• 30 затворени въпроса
• 45 минути
• Верен отговор = 1 т.; грешен = 0 т.
• Има два теста, носят по максимум 30 точки всеки
• Вторият тест ще е в края на семестъра и/или по време на сесията

• Ще включва материал, предаден до днес, включително
• За подготовка, прочетете слайдовете внимателно
• Ако ви изскочи нещо, което не разбирате, питайте във форумите, или ни пишете

• Преди теста в сряда няма да ви даваме други домашни
• Тази седмица най-много да пуснем едно предизвикателство четвъртък-петък
• Следваща задача ще има следващата седмица

• Web с Ruby, Sinatra
• Може би Rails, ако има достатъчно желаещи - може да пуснем една анкета за/против
• Ruby core & stdlib
• Конкурентност и паралелно програмиране в Ruby
• Алтернативни Ruby имплементации
• Още code spelunking
• GUI, UI, Gosu, Shoes и каквото друго ви е интересно
• Вие като лектори?

За какво се използва staging областта?

Как можем да видим списък от направените commit-и? Ами да разгледаме промените, направени в commit?

Можем ли да променим commit обект?

Какво е branch?

git merge killer-feature
git merge --squash killer-feature

• Слива промени от (най-често) 2 клона
• Често създава нов commit

Различни стратегии на сливане. Основните са 2:

• Fast-Forward
• Recursive

Слива 2 разделили се клона с обща история.

Жълтото e merge commit-a. Той съдържа промените и от двата клона.

git pull == git fetch && git merge origin/master

• Изтегля промените и ги слива с текущия бранч

git branch -d killer-feature
git push origin --delete killer-feature # Ако сте го push-нали
git push origin :killer-feature         # В по-стари версии

• Премахва само файла на branch-a, commit-ите се пазят
• Дори ако е останал commit, който е извън историята, пак може да се възстанови
• За възстановяване - след малко

Заради "евтините" branch-ове на git можем да направим следното:

• Имаме два основни branch-a - master и develop (internal, unstable или както го кръстите)
• Когато започваме нова функционалност, правим branch специално за тази промяна
• Когато приключим, я качваме в develop с git merge
• В develop нещата се тестват и след определено време се сливат с master

• В master имаме само стабилни промени
• В develop имаме новите функции, които не са достатъчно тествани
• Ако две нови функции си пречат, това може да се поправи, преди да влязат в стабилната версия
• Ако трябва бързо да поправим нещо в стабилната версия на кода, можем директно да направим commit в master

git reset <commit> <files>
git reset HEAD lectures/git.slim

• Променя файлове в staging областта, като ги взима от хранилището
• В случая HEAD указва от кой точно commit да се вземат файловете. Там може да има и хеш на commit
• Не променя файловете в работната директория
• Използва се, когато не искате да commit-вате файл, но да запазите локалните промени
• С —hard променя и работната директория

git checkout <files>
git checkout <commit> <files>
git checkout <branch> <files>

• Променя файлове в работната директория, като ги взима от staging областта...
• ... или от определен commit.
• Внимание! Може да изгубите код!

git commit --amend
git push --force   # Ако вече сте push-нали

• Променя последния commit. А дали наистина?
• Всъщност създава нов commit със същия предшественик
• Старият commit все още може да бъде възстановен
• Удобно е за поправяне на грешки в съобщението или добавяне на изпуснати файлове
• Не е хубаво да се прави, ако вече сте push-нали, защото някой друг може да е направил pull и ще има конфликт

git revert <commit>

• Премахва промените, направени от commit
• Всъщност създава нов commit, който прави същото като commit, но наобратно
• Разбирайте, където има + в diff-a, става на - и обратно
• Ако все пак решите, че искате тези промени, можете да revert-нете revert commit-a

git reflog

• Показва ви последните операции, които сте правили, заедно с ID-та на разни обекти
• Можете да намерите ID-тата на изгубени commit-и и да ги възстановите
• Понякога се чисти

• Често има файлове, които не искаме git да следи
• Например компилирани двоични файлове, временни файлове, конфигурационен файл с API ключове и т.н.
• Всеки ред в .gitignore е шаблон за файлове/директории, които трябва да бъдат игнорирани
• Това означава, че няма да се виждат в git status

git checkout killer-feature
git rebase master
git rebase -i master
git rebase -i HEAD~4
git pull --rebase

• Пресъздава промените от текущия branch, все едно са направени върху сегашното състояние на master
• С -i ви позволява да си премахнете, промените или слеете (squash) commit-и от историята
• Трябва да направите git push —force, ако вече сте push-нали branch-a, който променяте
• Отново - избягвайте да го правите, ако промените вече са публикувани

• git add, git commit
• git push, git pull
• git checkout
• git merge, git rebase -i
• git reflog

• Елегантно решение на сложен проблем
• Научавайки как работи на по-ниско ниво, ще ви помогне да се ориентирате
• Конзолният интерфейс е сложен, но ще разбирате какво става "под капака"

• Няма да минете без него...
• ...затова започвайте да го използвате...
• ...с терминала - научават се много неща.
• Може да ви се струва труден - не е

Искайте помощ:

• git command —help
• man git
• man git-command

• Добър туториал за начинаещи с терминалния интерфейс - Try git
• Безплатна книга с много подробни обяснения - Pro Git
• Инструкции за създаване на pull request в GitHub - Guide
• Интерактивна визуализация на команди - Explain Git (забележка: някои неща не са 1:1 с реален Git)

Сега е добър момент да ги зададете.

• http://fmi.ruby.bg/
• @rbfmi