Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».
Читать полностью »
Рубрика «git workflow» - 2
Изменение коммитов в Git
2013-11-12 в 22:25, admin, рубрики: Git, git workflow, метки: Git, git workflowВливание legacy-истории в дерево: нахождение оптимальной точки ответвления
2013-08-28 в 8:25, admin, рубрики: Git, git workflow, release management, Системы управления версиями, метки: Git, git workflow, release management 
По долгу службы мне досталась в наследство некая система, имеющая ~15 лет истории и порядка нескольких десятков инсталляций в разных организациях. Сама по себе системы относительно небольшая (~25K строчек кода, ~1K коммитов), но проблема была в release management:
- было основное дерево в subversion (изначально в cvs, разумеется), где проводился «основной курс партии» — делались какие-то масштабные изменения, добавлялись новые возможности, исправлялись глобальные ошибки и т.п.
- конкретные инсталляции делались путем:
- в лучшем случае — svn checkout, который потом обновлялся через svn update; почти во всех инсталляциях делались локальные доработки «на живую» (как минимум — правились конфигурационные файлы) и эти изменения никуда не коммитились; если при очередном svn update изменения в upstream создавали конфликт — конфликт ресолвился «на месте» тем программистом, который делал update, опять же, без какого-либо трекинга изменений
- в худшем случае — svn export, который потом, понятно, не обновлялся совсем, оставаясь раз и навсегда (или по крайней мере пока начальство не одумается) на уровне развития даты экспорта; в особо запущенных случаях (из конца 1990-х — начала 2000-х) так делали еще и потому, что просто не было физической возможности сделать checkout — в организации не было доступа в интернет, архив просто приносили на дискетке и разворачивали единожды на месте
На практике, разумеется, благодарные заказчики этой системы время от времени хотят все-таки получать поддержку, исправления багов и даже иногда какие-то глобальные доработки в ядре системы.
Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение
2013-08-20 в 11:00, admin, рубрики: aida, badoo, code coverage, git workflow, jira, teamcity, автоматическое тестирование, баду, Блог компании Badoo, Веб-разработка, тестирование, метки: aida, badoo, code coverage, git workflow, jira, teamcity, автоматическое тестирование, баду 
В июле мы вместе с ведущими IT-Kompot и релиз-инженерами Badoo Владиславом Черновым и Олегом Оямяэ записали выпуск подкаста «Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение».
Так как прошлый подкаст вызвал интерес у слушателей и читателей, то этот подкаст мы тоже превратили в статью.
О чем говорили:
Процесс разработки и выкатки релизов в компании Badoo. Используемые инструменты.
- GIT Workflow. Каждая задача в отдельной ветке;
- Использование JIRA, TeamCity и AIDA;
- Формирование релиза и выкатка двух релизов в день. Проблемы и их решения (откат, патчи и т.д.).
Автоматическое тестирование. Рецепт быстрого прогона большого количества тестов.
- Что мы используем;
- Как гоняем тесты;
- Code Coverage;
- Пускалка. 18000 тестов за 3,5 минуты.
Девелоперское окружение в команде, разрабатывающей сложную распределенную систему
И рекомендации от ребят: полезные книги, статьи и т.д.
Ежедневная работа с Git
2013-05-15 в 16:15, admin, рубрики: Git, git workflow, tutorial, Системы управления версиями, метки: Git, git workflow, tutorialЯ совсем не долго изучаю и использую git практически везде, где только можно. Однако, за это время я успел многому научиться и хочу поделиться своим опытом с сообществом.
Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:
- можно ли git «подстроить» под тот процесс разработки, который мне нужен?
- будет ли менеджер и заказчик удовлетворён этим процессом?
- будет ли легко работать разработчикам?
- смогут ли новички быстро включиться в процесс?
- можно ли процесс относительно легко и быстро изменить?
Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.
Постигаем Git
2012-04-03 в 5:41, admin, рубрики: Git, git workflow, контроль версий, разработка, Системы управления версиямиОт переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.
Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.
Читать полностью »