Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.
Рубрика «Git» - 7
Как привести в порядок историю ваших коммитов в Git
2020-04-02 в 13:04, admin, рубрики: Git, github, tutorial, Блог компании Plarium, история коммитов, коммит, парное программирование, Программирование, Системы управления версиями
Собираем свой flow для git с нуля
2020-03-24 в 10:01, admin, рубрики: Git, gitflow, github flow, gitops, архитектура гита, дожили, Программирование, Системы управления версиями, управление проектами, управление разработкойНа днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
- GitFlow противоречит тезису "ветки должны быть короткоживущими".
Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических) - GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого. - GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
- GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
-
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
Так что делать-то?
GitLab CI: 6 фич из последних релизов, которых мы так ждали
2020-03-16 в 9:06, admin, рубрики: devops, Git, gitlab, gitlab ci, Блог компании Флант, системное администрирование
В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.
Агрегация по месяцам и тегам репозитория GitLab
GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.
О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.Читать полностью »
Пожалуйста, перестаньте рекомендовать Git Flow
2020-03-09 в 10:05, admin, рубрики: Git, gitflow, Блог компании Флант, ПрограммированиеПрим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.
Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).
За последние десять лет бесчисленное множество команд пали жертвой этого громкого названия и оказались — не побоюсь этого слова — откровенно облапошены. В своей заметке автор утверждает, что они успешно внедрили эту модель в проекты, но умышленно не раскрывает подробности проектов, которые привели к этой «успешности».
И это главная ошибка тех, кто верит данной публикации. Общеизвестен факт, что не все стратегии работают во всех ситуациях, со всеми людьми, во всех контекстах. И я утверждаю, что та же логика применима и к этой модели ветвления.
На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.Читать полностью »
Laravel+Docker+Gitlab. С чего начать
2020-03-08 в 9:20, admin, рубрики: docker, docker-compose, Git, gitlab, laravel, phpЯ обычно всегда обходился без докера и думал, что докер нужен только для больших проектов в больших компаниях. Но однажды я увидел как работает докер в паре с гитлабом у моего товарища и понял, что мне все таки стоит его изучить. Однако, как обычно это бывает, одной подходящей статьи я не нашел — они были либо слишком сложные, либо не полные, либо подразумевали, что вы все знаете само собой. Мне пришлось долго искать различные источники, соединять все это вместе и в итоге у меня получилось сделать простенький проект и CI/CD для него.
Всю работу можно разделить на три части: на локальной машине, на гитлабе и на сервере.
Итак, для реализации проекта нам понадобится аккаунт gitlab и удаленный сервер с виртуализацией KVM или XEN.
Часть 1. Локальная машина
На локальной машине необходимо установить docker.
Замечание
Тут небольшое отступление. Docker можно поставить как на Linux системах (как Ubuntu, например), так и на Windows и MacOS. По поводу macos я ничего сказать не могу, а вот установка под Windows не самая хорошая идея для начинающего. Как минимум из-за того, что все мануалы и документации написаны для linux систем. Так и из-за того, что можно нажить проблем с доступом к различным папкам и файлам. Также докер конфликтует с виртуальной машиной VirtualBox. Поэтому проще и быстрее будет сделать виртуальную машину с Ubuntu и работать под ней
Как Gitlab-CI наследует переменные окружения?
2020-03-07 в 16:12, admin, рубрики: devops, environment variables, Git, gitalb-ci, gitlab, inheritance, pipelines, системы сборкиПеременные в Gitlab можно задать в нескольких местах:
- В настройках групп
- В настройках проекта
- Внутри .gitlab-ci.yml
При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".
Начнем с простого наследования и будет постепенно усложняться.
С конечным списком уровней приоритетов можно ознакомиться в конце документа.
Исправление проблем под Docker. Казалось бы, при чём здесь GIT?
2020-03-03 в 13:39, admin, рубрики: devops, docker, Git, mount, smb, troubleshooting, виртуализация, микросервисы
Докер под Windows — это постоянные приключения. То ему нужно обновить операционку, иначе последние версии не ставятся, то он забывает, как подключаться к сети. В общем, каждый день от него новости. «Поставил и забыл» — это не про Docker Desktop for Windows. Особенно, когда он используется не совсем так, как рекомендуют его разработчики. А они почему-то не одобряют подключение внешних windows сетевых дисков в качестве локальных. И совсем не одобряют доступ к к таким сетевым папкам, которые расположены ещё и на host машине. Пишут, что это ужас-ужас с точки зрения безопасности, требуют всяких ключей типа:
cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH
для работы команды mount в контейнере и прочая, и прочая.
Читать полностью »
Ревью кода системы средствами git
2020-03-01 в 20:34, admin, рубрики: bitbucket, code review, Git, github, gitlab, управление разработкойБывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
Code review — улучшаем процесс
2020-02-25 в 12:45, admin, рубрики: codereview, Git, merge request, pull request, комманда, отладка, проверка кода, Программирование, процесс разработки, психология, Совершенный код, управление разработкой
Представим команду, где не проводится Code review. Разработчики пишут код и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда при любом мало-мальском нововведении проект начнёт разваливаться: в лучшем случае, увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.
Как этого можно избежать? Читать полностью »
Вышла бета консольной утилиты GitHub CLI
2020-02-13 в 8:30, admin, рубрики: Git, github, GitHub CLI, ITSumma, open source, Блог компании ITSumma, командная строка, консоль, Софт, утилита
Разработчики GitHub выпустили бета-версию консольной утилиты GitHub CLI. Она позволяет создавать пул-реквесты и тикеты на GitHub, не выходя из консоли, где вы уже работаете с git.
Пул-реквесты и issue — самые распространённые команды, поэтому их добавили в первую очередь.
Как и прошлая программа Hub, эта полностью написана на Go. Она тоже запускается в разных ОС, включая Linux, MacOS и Windows, причём гораздо удобнее в использовании.
Читать полностью »