Няколко трика за работа с git
Докато четях уроци за git контрол на версиите, забелязах една функция, повечето от тях са насочени към това да накарат читателя да разбере всички предимства на разпределената система за контрол на версиите. В този раздел обикновено се говори за отдалечени хранилища, клонове, натискания, пулове и т.н.
Разбира се, може да се окаже, че такъв подход трябва да се приложи от самото начало ... дори не може, но трябва да се приложи от самото начало, но както обикновено, не винаги има достатъчно време, усилия, желание и т.н. за нормално проучване.
Файлова анотация
Нерядко се случва ситуация, когато откриете някакъв бъг в кода и става страшно интересно кой и кога го е написал. (Все пак, разбира се, искам да знам какво си е помислил в същото време и на кое място е натиснал бутоните, но тук, разбира се, джитът е безсилен)
git blame ви позволява да видите кога и от кого всеки ред от даден файл е бил последно редактиран.
git blame -L 12.22 products.php
Също така си струва да се отбележи, че ако зададете опцията -C за командата, можете да видите къде първоначално се е появил необходимият кодов фрагмент в хранилището, без значение към кой файл е бил първоначално добавен.
git blame -L 10,19 -C Controller.php
Двоично търсене
Втората функция, за която бих искал да говоря, е възможността за двоично търсене при ангажименти. Нека ви дам следната ситуация като пример. Някаква функционалност се повреди в нашия проект, не можем да разберем какъв точно е проблемът, но знаем със сигурност, че тази функционалност работи точно в последната версия. Така че командата bisect ни позволява лесно да върнем назад проекта за даден брой ангажименти и да намерим ангажимента, в който неуловим бъг се появява за първи път.
Първо стартираме търсачката и задаваме стойността, че текущото състояние на проекта не работи
След това се връщаме къмработно състояние на проекта - 10 ангажимента назад в историята
git разполовява добра ГЛАВА
Да видим дали тази грешка се проявява в текущото състояние. Да кажем, че сега всичко е наред с проекта, така че продължаваме търсенето по-нататък
git разполовява добре
След като търсенето приключи, нулирайте хранилището до първоначалното му състояние
git разполовява нулиране
Връщайки се към въведението, искам да кажа, че при преподаването на Гита за мен, тази книга се превърна в такава книга, която би поставила точка на всички e. Може би не е най-подробната презентация, но според мен за прехода от състоянието „Мога да го направя“ към състоянието „Мога да го направя и да разбера защо е необходимо да го направя по този начин“ е много добър вариант. Има и превод (макар и не съвсем пълен) на български.
С това искам да завърша моята история, надявам се описаната функционалност да бъде полезна в работата не само за тези, които тепърва откриват git.
UPD.Тази функционалност съществува и за Mercurial, благодарение на retran blame — hg annotate И има специален плъгин за търсене — mercurial.selenic.com/wiki/BisectExtension
За svn има svn blame TARGET[@REV]
Hardcore conf в C++. Каним само професионалисти.