Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.
Рубрика «rebase»
Clean Git History, или Тёмная сторона VCS
2023-08-15 в 12:43, admin, рубрики: Git, ozon tech, rebase, VCS, коммит, чистый кодПоддержание аккуратной истории в Git с помощью интерактивного rebase
2021-01-12 в 6:21, admin, рубрики: Git, rebase, Блог компании Флант, ПрограммированиеПрим. перев.: эта статья была написана автором Git-клиента Tower, Tobias Günther, и опубликована в блоге GitLab. В ней просто и наглядно рассказывается об основных возможностях интерактивного rebase'а, что может стать отличным введением для тех, кто только начинает им пользоваться.
Interactive rebase — один из самых универсальных инструментов Git'а. В этой статье мы поговорим о том, как с его помощью корректировать сообщения при коммитах, исправлять ошибки, и о многом другом.
Руководство по Git. Часть №2: золотое правило и другие основы rebase
2020-04-24 в 7:33, admin, рубрики: branch, commit, Git, Mail.Ru Cloud Solutions, pull, rebase, Блог компании Mail.Ru GroupПосмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным.
Это вторая и третья части гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. Первую часть можно почитать тут.
Читать полностью »
Как научить людей использовать Git
2019-01-21 в 17:29, admin, рубрики: fetch, Git, github, merge, pull, rebase, система управления версиямиПо работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.
Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.
Читать полностью »
Как и зачем красть деревья в git
2018-12-20 в 6:35, admin, рубрики: commit, conflict, Git, merge, rebase, tree, Системы управления версиями
В этой статье я расскажу об одном полезном, но малоизвестном приеме работы с git — как можно легко создать коммит, используя дерево из другого коммита. Проще говоря, как получить нужное состояние проекта на какой-либо ветке, если это состояние уже когда-то и где-то было в репозитории раньше. Будет приведено несколько примеров того, как это позволяет элегантно решать некоторые практические задачи. И в частности я расскажу о найденном мной методе, который позволяет значительно упростить исправление множественных конфликтов при rebase. Кроме того, эта статья — отличный способ понять на практике, что из себя представляет коммит в git-е.
Введение в Git Merge и Git Rebase: зачем и когда их использовать
2018-12-07 в 13:19, admin, рубрики: Git, merge, rebase, система контроля версийЧасто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Git Merge
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.Читать полностью »
Рецепт полезного код-ревью от разработчика из Яндекса
2018-09-06 в 7:10, admin, рубрики: agile, codereview, Git, github, javascript, rebase, review, Блог компании Яндекс, Программирование, ревью, ревью кода
Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.
С помощью код-ревью я постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: "А что, так тоже можно?". В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть мои пулреквесты. Это мотивирует писать красивый и понятный код.
Но так было не всегда. Когда-то ревью было для меня наказанием. Я мог неделю с вдохновением писать код, вкладывая в него все силы. Отправлял пулреквест, трижды пинговал ревьювера, а в ответ получал сухое "вроде ок" или, что ещё хуже, десятки комментариев не по существу.
Мне на ревью приходили пулы из пяти тысяч строк. Я часами пытался разобраться в коде, по сотне раз скроллил от функции к тесту и обратно. Писал десятки бесполезных комментариев о пропущенной точке с запятой. Всё это жутко меня раздражало. Часто откладывал ревью на потом, и у меня накапливались десятки непросмотренных пулов.
Если вы чувствовали это на себе, значит, статья для вас. Сегодня я расскажу о приёмах и инструментах, которые использую каждый день на протяжении пяти лет ежедневного код-ревью.
Почему нужно перестать использовать Git rebase
2017-10-23 в 12:06, admin, рубрики: Git, rebase, Блог компании Mail.Ru Group, никто не читает теги, Программирование, Разработка веб-сайтов, Системы управления версиями
После нескольких лет работы с Git я обнаружил, что постепенно стал переходить на всё более сложные Git-команды в рабочем процессе. Вскоре после того как я открыл для себя Git rebase, я тоже быстро внедрил эту команду в повседневные задачи. Те, кто знаком с этой процедурой, знают, насколько это мощный инструмент и какой это соблазн — постоянно им пользоваться. Но вскоре оказалось, что rebase влечёт за собой ряд неочевидных на первый взгляд трудностей. Но прежде чем обсудить их, хочу быстро рассмотреть различия между merge и rebase.
Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket
2016-05-11 в 15:10, admin, рубрики: bitbucket, Git, gitflow, github, gitlab, merge, rebase, Блог компании AT Consulting, Программирование, Системы управления версиями, управление разработкойНемного истории
В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.
С этого момента описанная модель ветвления GitFlow, начинает, что называется, расходиться по миру. Её берут на вооружение многие команды. Авторы пишут много статей об успешном её использовании. Она получает поддержку в большинстве инструментов, которые используют разработчики:
- Плагин к самому Git'у
- Плагины к различным IDE: IDEA, Eclipse
- Встроенная поддержка в GUI клиентах: SourceTree и Git Extensions
- Плагины для систем сборки: Maven, Gradle, и т.д.
- Встроенная поддержка в менеджерах репозиториев: GitHub, BitBucket, GitLab и т.д.
Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.
Что там в Git 2.8? Push, grep, rebase, config и прочие штуки
2016-04-07 в 14:35, admin, рубрики: config, Git, git 2.8, grep, pull, push, rebase, метки: git 2.8Вышел новый Git 2.8.0! В течение пары последних недель, когда релиз был в стадии кандидата, я прошёлся по списку коммитов и заметок к нему, пробуя новые вещи и отмечая интересные моменты. Чтобы сохранить ваше время, предлагаю субъективную выборку фич, которые стоит попробовать. Пользуйтесь!
Краткий вариант push -d, синоним push --delete
Это отличное дополнение как для полноты множества опций, так и для скорости набора команд. Возможно, вы уже используете git branch -d, чтобы удалять локальную ветку, а теперь можно так же сократить команду удаления remote-ветки до git push -d.
git branch -d my-branch # удаляет локальную ветку, если она уже слита
git push -d origin my-branch # удаляет remote-ветку в origin-репозитории