
Рассказываем о новых возможностях сайта и топовых майских материалах. Сводим вместе подборки YouTube-каналов и лучших книг по различным языкам программирования 📽️📕
https://proglib.io/sh/e5iyMIdfrY
Size: a a a




git blame <filename>. Она относится к инструментам Git и помогает в поиске ошибок. git blame позволяет снабдить файл аннотацией, и таким образом увидеть, когда каждая строка файла была изменена последний раз и кем.-L:git blame -L 5,25 <filename>






git reflog, которая относится к командам, позволяющим восстановить данные в Git. Например, в какой-то момент при работе с Git вы можете нечаянно потерять коммит. Как правило, такое случается, когда вы удаляете ветку, в которой находились некоторые наработки, а потом оказывается, что они всё-таки были нужными (или выполнили git reset --hard, чем спровоцировали откат от коммитов, которые затем понадобились). git reflog, которая покажет коммит, который вы потеряли. После чего  коммит можно восстановить, создав ветку, указывающую на него, с помощью команды git branch <branch-name> <hash-commit>, которая  создаст ветку, указывающую туда, куда ранее указывал master, тем самым делая потерянные коммиты вновь доступными.git log может не показать вам эти коммиты, более того, если вы использовали git reset, которая никогда не удаляет коммиты, однако может оставить их без родителя, т. е. указатель потеряет прямой путь для доступа к ним.  Такие коммиты без родителя обычно можно найти и восстановить с помощью команды git reflog.reflog, то это можно объяснить следующим образом: garbage collector ищет объекты, на которые больше нет ссылок, и удаляет их из хранилища, при этом огромную роль играет журнал операций reflog (ссылки в нем имеют ограниченный срок жизни, по умолчанию 30 дней для объекта без ссылок и 90 дней для объекта со ссылками). Garbage collector сначала удаляет из журнала reflog все ссылки с истекшим «сроком годности», а затем удаляет из хранилища объекты, на которые больше нет ссылок. Такая архитектура дает разработчику 30 дней, чтобы восстановить «ненужный» коммит, который в противном случае будет окончательно удален из репозитория по истечении этого срока.





Клиентские хуки запускается до любого другого хука и до коммита любых изменений. Из них самым распространённым является хук pre-commit. Серверные хуки выполняются на стороне сервера и делятся на подкатегории:pre-receive и post-receive: выполняются на сервере, который получает задачу push, для выполнения таких действий, как проверка целостности проекта и развертывание;update (хуки обновления): похожи на pre-receive, но работают по принципу ветвления для выполнения кода перед принятием каждой ветки.

