Большое количество метаданных, хранящихся в git, и встроенные способы получения отчетов по ним дает некоторые инструменты для поиска источников тех или иных багов в коде. [Читать далее…]

Git-flow — наиболее популярная методология разработки проектов с использованием git.

Зачем нам вообще нужны какие-то методологии для работы с git?

Дело в том, что сам git не привязывает нас к какому-либо определённому способу разработки, и каждый разработчик, в теории, может работать с контролем версий так, как он хочет. Чтобы в таких условиях не погрузить наш репозиторий в хаос, нам нужно придумать и донести до всех разработчиков некий единый стандарт для работы с контролем версий в проекте.

Git-flow даёт нам готовый стандарт проверенный временем и уже известный многим разработчикам.

В то же время, нужно понимать, что методология git-flow не является единственно верной и на 100% универсальной. В Вашем проекте может существовать собственный подход к работе с git. Однако, если вы работаете или собираетесь работать с git в команде, то стоит знать о том, что такое git-flow и в чём его особенности.

И так, что же нам стоит знать о git-flow? [Читать далее…]

Пример ситуации: Вы делаете коммит текущего (не совсем стабильного) состояния рабочей копии, чтобы быстро поработать над какими-то другими задачами. Затем, вернувшись к работе над неоконченной задачей и завершив её вы делаете коммит и … понимаете что забыли проставить “amend”.

История коммитов получается примерно следующая.

ae02b31‌ Хорошие правки [develop]
d8428ca НЕ ПУШИТЬ! Неоконченные хорошие правки
3a18c32 Предыдущие и безусловно тоже хорошие правки [origin/develop]

Не отправлять же такое на сервер? А вот и не придётся.

Мы можем объединить последние два коммита в один, и дать ему хорошее название.

Сделать это очень просто: нам нужно мягко откатиться до коммита, который предшествует нашим неоконченным правкам и затем сделать commit. Вот и всё.

Вместо 3a18c32 подставьте хеш последнего коммита, который был до тех, что вы хотите объединить.

Стоит помнить что это изменение истории. Другими словами, если вы уже сделали push своих недоделанных правок на сервер, то менять их крайне нежелательно.

Одним из недостатков rebase является то, что при неумелом разрешении конфликтов (особенно в бинарных файлах), можно потерять нужную версию файла. Ещё один хороший способ потерять коммит, это удалить ветку, в которой он находится.

Do not panic!

В случае git, “потерять” — это не совсем верное слово. Git хранит последние коммиты, которые больше не находятся в истории, но ещё могут быть туда возвращены.

И так, предположим, мы сделали что-то не так и “потеряли” файл или целый коммит.

[Читать далее…]

Бывают ситуации, когда нужно получить из репозитория большие правки по очень узкому каналу связи. Это может стать большой проблемой при периодических разрывах связи.

Git скачивает изменения потоком, никакие Download Master’ы тут не помогут. Казалось бы.

[Читать далее…]