Рубрика «githooks»

Позвольте мне рассказать вам историю. Жили-были два разработчика: Сэм и Боб. Они вместе работали над проектом, в котором была база данных. Когда разработчик хотел внести в неё изменения, он обязан был создать файл stepNNN.sql, где NNN — некоторое число. Чтобы избежать конфликтов этих чисел между различными разработчиками, они использовали простой Web-сервис. Каждый разработчик прежде чем начать писать SQL-файл должен был зайти на этот сервис и зарезервировать за собой новое число для step-файла.

В этот раз Сэму и Бобу обоим нужно было внести изменения в базу данных. Сэм послушно отправился на сервис и зарезервировал за собой число 333. А Боб забыл сделать это. Он просто использовал 333 для своего step-файла. Так случилось, что в этот раз Боб первым залил свои изменения в систему контроля версий. Когда Сэм был готов залиться, он обнаружил, что файл step333.sql уже существует. Он связался с Бобом, объяснил ему, что номер 333 был зарезервирован за ним и попросил исправить конфликт. Но Боб ответил:

— Чувак, мой код уже в 'master'е, куча разработчиков уже используют его. К тому же он уже выкачен на production. Так что просто исправь там у себя всё, что нужно.

Надеюсь, вы заметили, что произошло. Наказанным оказался человек, который следовал всем правилам. Сэму пришлось менять свои файлы, править свою локальную базу данных и т.д. Лично я ненавижу такие ситуации. Давайте посмотрим, как мы можем избежать её.

Читать полностью »

Принимая решение об использовании того или иного средства в собственных проектах, инженеру приходится не только изучать сопроводительную документацию, но и проводить серию экспериментов для того, чтобы избежать потенциальных проблем в будущем. Если же речь идет о CM-политике, рассчитанной на длительную перспективу, цена ошибки выбора становится достаточно высока.

Целью настоящей работы является практическое изучение средства управления поддеревьями Git.

Начиная с ревизии 1.7.11 upstream-репозиторий Git, в каталоге contrib/subtree, содержит средство автоматизации работы с поддеревьями.

Сервис git-subtree(1) фактически является полезной надстройкой, использующей функции git-read-tree(1) и git-write-tree(1). Поэтому ссылки в командах git-subtree(1) add/pull/push:

  git subtree add --prefix=<subdir> <remote> <ref>

могут представлять собой, как имена веток, так и имена тегов удаленного репозитория.

Кроме того, если заранее добавить удаленный репозиторий в конфигурационный файл локального репозитория .git/config, с помошью команды:

bash-4.4$ git remote add build-system ../../remote/build-system.git

где build-system является именем удаленного репозитория ../../remote/build-system.git, то в дальнейшем, при использовании команд git-subtree(1) add/pull/push, мы сможем ссылаться на upstream-репозиторий remote/build-system.git по имени.

На данный момент git-subtree(1) практически не развивается, а лишь поддерживается в актуальном состоянии для текущей степени развития проекта Git.

Однако git-subtree(1) является наиболее популярным и мощным средством работы с поддеревьями.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js