Презентация методологии git-flow для стабильной разработки
Текстовая версия: https://medium.com/ruopsdev/git-flow-presentation-b80643390888
Скачать презентацию в формате pptx: https://docs.google.com/presentation/d/1Bgx5GP9ykGYKUnAaD53Y0YIpPpHHSbvT/edit?usp=sharing&ouid=106302903983671723423&rtpof=true&sd=true
Антон Григорьев, Git-flow: как построить процесс разработки и быстро получать...ScrumTrek
Работаете над проектом втроем (вчетвером, впятером, вдесятером и тд) и у вас постоянные конфликты в системе контроля версий? - В спешке пытаетесь собрать проект, но не можете найти рабочую версию, а клиент просит здесь и сейчас? - Процесс тестирования и выпуск новой версии - стресс для вас и вашей команды? Решить эти и другие проблемы поможет git-flow. Вы узнаете, как git-flow связан с процессом непрерывной интеграции, как это поможет быстро доставлять вашим клиентам исправления критических ошибок и как эти изменения автоматически попадут в текущую версию продукта. Приходите, если даже просто интересно, причем тут git и подойдет ли SVN, Hg или TFS?
Git Flow is a strict branching model for managing workflow in Git projects. It was created by Vincent Driessen to provide a robust framework for managing features, releases, and bug fixes. The model uses long-living branches for development (develop), releases (master), features, and hotfixes, along with clear guidelines on how to integrate these branches. It aims to make collaboration easier by clearly defining roles for different branches and standardizing the development process.
This document introduces Git Flow, a Git branching model that provides high-level repository operations. It outlines the main branches - master for production, develop for development, and supporting branches like feature, release, and hotfix. Git Flow is a collection of Git extensions that help initialize and manage branches through commands like git flow feature and git flow release. The model forms an easy to understand mental model for teams to share in their branching and releasing processes.
GitFlow is a branching model for Git, created by Vincent Driessen. It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team
This document discusses Git flow and workflows for features, releases, and hotfixes. It explains how to start and finish these branches using git flow commands or equivalent Git commands. It also provides tips for publishing remote branches, dealing with obsolete branches, and fixing common mistakes like amending commits, resetting files, and recovering deleted local branches.
Антон Григорьев, Git-flow: как построить процесс разработки и быстро получать...ScrumTrek
Работаете над проектом втроем (вчетвером, впятером, вдесятером и тд) и у вас постоянные конфликты в системе контроля версий? - В спешке пытаетесь собрать проект, но не можете найти рабочую версию, а клиент просит здесь и сейчас? - Процесс тестирования и выпуск новой версии - стресс для вас и вашей команды? Решить эти и другие проблемы поможет git-flow. Вы узнаете, как git-flow связан с процессом непрерывной интеграции, как это поможет быстро доставлять вашим клиентам исправления критических ошибок и как эти изменения автоматически попадут в текущую версию продукта. Приходите, если даже просто интересно, причем тут git и подойдет ли SVN, Hg или TFS?
Git Flow is a strict branching model for managing workflow in Git projects. It was created by Vincent Driessen to provide a robust framework for managing features, releases, and bug fixes. The model uses long-living branches for development (develop), releases (master), features, and hotfixes, along with clear guidelines on how to integrate these branches. It aims to make collaboration easier by clearly defining roles for different branches and standardizing the development process.
This document introduces Git Flow, a Git branching model that provides high-level repository operations. It outlines the main branches - master for production, develop for development, and supporting branches like feature, release, and hotfix. Git Flow is a collection of Git extensions that help initialize and manage branches through commands like git flow feature and git flow release. The model forms an easy to understand mental model for teams to share in their branching and releasing processes.
GitFlow is a branching model for Git, created by Vincent Driessen. It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team
This document discusses Git flow and workflows for features, releases, and hotfixes. It explains how to start and finish these branches using git flow commands or equivalent Git commands. It also provides tips for publishing remote branches, dealing with obsolete branches, and fixing common mistakes like amending commits, resetting files, and recovering deleted local branches.
Git-flow is a Git workflow that advocates using separate branches for features, releases, and hotfixes. It uses a master branch for production-ready code and a develop branch as the main branch where features are integrated. Feature branches are created from develop and merged back after completion. Release branches are created from develop for final testing before merging to both master and develop. Hotfix branches are directly created from master to quickly patch production releases. Pull requests are recommended to communicate changes between branches.
Trunk-based development is a workflow where developers work directly on a main branch called the "trunk". The trunk is always in a deployable state. Short lived branches are used for developing new features which are then merged into the trunk after passing tests. Releases are cut from the trunk periodically. This allows for continuous integration and deployment while maintaining a stable release.
Two days git training with labs
First day covers git basis and essential commands
Second day covers git additional command with a big lab using a git workflow
This document provides an overview of various Git commands, workflows, and best practices. It covers the basics of initializing repositories, committing, branching, merging, tagging, undoing changes, and working with remotes. It also summarizes several common Git workflows including centralized, feature branching, Gitflow, and forking models. Best practices around aliases, ignoring files, log formatting, and branching strategies are also outlined.
Are you sick of Merge Hell? Do your feature branches go rogue? Do you spend more time fiddling with your Version Control System than doing actual development work? Then Trunk Based Development might be for you. Facebook does it. Google does it. Instead of messing with multiple branches, just use your master branch. Always. In addition to giving you an overview about how Trunk Based Development works, where it shines and where the pitfalls are, this talk will also cover the necessary techniques to succeed with it, such as Branch By abstraction, Feature Toggles and backwards compatible Database Migrations.
Github - Git Training Slides: FoundationsLee Hanxue
Slide deck with detailed step breakdown that explains how git works, together with simple examples that you can try out yourself. Slides originated from http://teach.github.com/articles/course-slides/
Author: https://twitter.com/matthewmccull
A Beginner's Guide to Git and GitHub, CLI version.
What is Git?
What is Github
Basic commands
Difference between Central and Distributed Version Controlling System
Git is a distributed version control system that records changes to files over time. It allows multiple developers to work together and tracks the version history. The document outlines the basic concepts and commands of Git including repositories, commits, branches, merging, cloning, pulling and pushing changes between a local and remote repository. Examples are provided to demonstrate how to initialize a local repository, add and commit changes, switch branches, and push updates to a remote server.
The document discusses different types of Git workflows including centralized, feature branch, and forking workflows. It mentions the centralized workflow allows developers comfortable with Subversion to experience Git benefits without entirely new processes, serving as a friendly transition. Feature branches are developed independently then merged into the main branch, while forking lets anyone contribute by making changes on their personal fork then submitting a pull request.
This document discusses GitFlow, SourceTree, and GitLab for software development workflows. It provides an overview of main and supporting branch types in GitFlow like develop, master, feature, release and hotfix. It also summarizes the key features and uses of SourceTree for visualizing Git repositories and GitLab for hosting Git repositories and providing features like activity streams, code review, issues and more.
What is version control software and why do you need it?Leonid Mamchenkov
Version control software (VCS) manages changes to files such as documents, images, and code. It allows users to undo changes, try ideas, collaborate, and troubleshoot. VCS originated from engineering blueprints and software development in the early UNIX days. It works by storing revisions in a repository with branches and tags. Git is the most commonly used VCS as it is free, distributed, fast, and the standard for open source projects. Users can get started by installing Git, configuring user information, initializing repositories for projects, and committing file changes with descriptive messages.
GitHub is a web-based hosting service for version control using git. It is mostly used for computer code. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its own features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project
This document discusses Git branching models and conventions. It introduces common branches like master, release, production and hotfix branches. It explains how to create and switch branches. Feature branches are used for new development and hotfix branches are for urgent fixes. Commit messages should include the related Jira issue number. The branching model aims to separate development, release and production stages through distinct branches with clear naming conventions.
Git is a version control system that stores snapshots of files rather than tracking changes between file versions. It allows for offline work and nearly all operations are performed locally. Files can exist in three states - committed, modified, or staged. Commits create snapshots of the staged files. Branches act as pointers to commits, with the default branch being master.
This document summarizes a presentation given at DrupalCamp in Athens on December 12, 2010 about Git and GitHub. The presentation introduced Git as a distributed version control system designed for speed and efficiency. It explained some of Git's core concepts like snapshots, branches, merging, and its distributed nature. It also promoted GitHub as a social coding platform that improves collaboration and code hosting for both open source and private projects. The presentation aimed to help attendees learn Git for their own benefit and prepare for Drupal moving to GitHub.
Introduction to GitHub, Open Source and Tech ArticlePRIYATHAMDARISI
The document provides an introduction to Git and GitHub. It begins with an agenda that outlines topics like commands, a demo, open source, and conclusion. It then discusses what Git is, the need to learn version control, and demonstrates some basic Git commands. It also covers topics like open source opportunities and general discussions.
This document provides an introduction to Git and GitHub. It outlines the basics of Git including initializing repositories, tracking changes, branching, merging, and resolving conflicts. It also covers GitHub concepts such as cloning repositories from GitHub to a local machine and pushing/pulling changes between local and remote repositories. The document explains how to collaborate on projects hosted on GitHub using Git.
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyerNoa Harel
AppsFlyer migrated from BitBucket to GitLab for their 150 users and 680 repositories. They wanted to leave the hosted BitBucket solution due to API call limits and latency. The migration process involved converting repositories from Mercurial to Git, setting up the GitLab architecture on Amazon Web Services with an EFS file system, educating teams, and creating custom tooling like a Python script to notify Slack. Lessons learned included issues restoring backups and increasing Unicorn workers. The full technical details are available at the provided URL.
Git-flow is a Git workflow that advocates using separate branches for features, releases, and hotfixes. It uses a master branch for production-ready code and a develop branch as the main branch where features are integrated. Feature branches are created from develop and merged back after completion. Release branches are created from develop for final testing before merging to both master and develop. Hotfix branches are directly created from master to quickly patch production releases. Pull requests are recommended to communicate changes between branches.
Trunk-based development is a workflow where developers work directly on a main branch called the "trunk". The trunk is always in a deployable state. Short lived branches are used for developing new features which are then merged into the trunk after passing tests. Releases are cut from the trunk periodically. This allows for continuous integration and deployment while maintaining a stable release.
Two days git training with labs
First day covers git basis and essential commands
Second day covers git additional command with a big lab using a git workflow
This document provides an overview of various Git commands, workflows, and best practices. It covers the basics of initializing repositories, committing, branching, merging, tagging, undoing changes, and working with remotes. It also summarizes several common Git workflows including centralized, feature branching, Gitflow, and forking models. Best practices around aliases, ignoring files, log formatting, and branching strategies are also outlined.
Are you sick of Merge Hell? Do your feature branches go rogue? Do you spend more time fiddling with your Version Control System than doing actual development work? Then Trunk Based Development might be for you. Facebook does it. Google does it. Instead of messing with multiple branches, just use your master branch. Always. In addition to giving you an overview about how Trunk Based Development works, where it shines and where the pitfalls are, this talk will also cover the necessary techniques to succeed with it, such as Branch By abstraction, Feature Toggles and backwards compatible Database Migrations.
Github - Git Training Slides: FoundationsLee Hanxue
Slide deck with detailed step breakdown that explains how git works, together with simple examples that you can try out yourself. Slides originated from http://teach.github.com/articles/course-slides/
Author: https://twitter.com/matthewmccull
A Beginner's Guide to Git and GitHub, CLI version.
What is Git?
What is Github
Basic commands
Difference between Central and Distributed Version Controlling System
Git is a distributed version control system that records changes to files over time. It allows multiple developers to work together and tracks the version history. The document outlines the basic concepts and commands of Git including repositories, commits, branches, merging, cloning, pulling and pushing changes between a local and remote repository. Examples are provided to demonstrate how to initialize a local repository, add and commit changes, switch branches, and push updates to a remote server.
The document discusses different types of Git workflows including centralized, feature branch, and forking workflows. It mentions the centralized workflow allows developers comfortable with Subversion to experience Git benefits without entirely new processes, serving as a friendly transition. Feature branches are developed independently then merged into the main branch, while forking lets anyone contribute by making changes on their personal fork then submitting a pull request.
This document discusses GitFlow, SourceTree, and GitLab for software development workflows. It provides an overview of main and supporting branch types in GitFlow like develop, master, feature, release and hotfix. It also summarizes the key features and uses of SourceTree for visualizing Git repositories and GitLab for hosting Git repositories and providing features like activity streams, code review, issues and more.
What is version control software and why do you need it?Leonid Mamchenkov
Version control software (VCS) manages changes to files such as documents, images, and code. It allows users to undo changes, try ideas, collaborate, and troubleshoot. VCS originated from engineering blueprints and software development in the early UNIX days. It works by storing revisions in a repository with branches and tags. Git is the most commonly used VCS as it is free, distributed, fast, and the standard for open source projects. Users can get started by installing Git, configuring user information, initializing repositories for projects, and committing file changes with descriptive messages.
GitHub is a web-based hosting service for version control using git. It is mostly used for computer code. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its own features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project
This document discusses Git branching models and conventions. It introduces common branches like master, release, production and hotfix branches. It explains how to create and switch branches. Feature branches are used for new development and hotfix branches are for urgent fixes. Commit messages should include the related Jira issue number. The branching model aims to separate development, release and production stages through distinct branches with clear naming conventions.
Git is a version control system that stores snapshots of files rather than tracking changes between file versions. It allows for offline work and nearly all operations are performed locally. Files can exist in three states - committed, modified, or staged. Commits create snapshots of the staged files. Branches act as pointers to commits, with the default branch being master.
This document summarizes a presentation given at DrupalCamp in Athens on December 12, 2010 about Git and GitHub. The presentation introduced Git as a distributed version control system designed for speed and efficiency. It explained some of Git's core concepts like snapshots, branches, merging, and its distributed nature. It also promoted GitHub as a social coding platform that improves collaboration and code hosting for both open source and private projects. The presentation aimed to help attendees learn Git for their own benefit and prepare for Drupal moving to GitHub.
Introduction to GitHub, Open Source and Tech ArticlePRIYATHAMDARISI
The document provides an introduction to Git and GitHub. It begins with an agenda that outlines topics like commands, a demo, open source, and conclusion. It then discusses what Git is, the need to learn version control, and demonstrates some basic Git commands. It also covers topics like open source opportunities and general discussions.
This document provides an introduction to Git and GitHub. It outlines the basics of Git including initializing repositories, tracking changes, branching, merging, and resolving conflicts. It also covers GitHub concepts such as cloning repositories from GitHub to a local machine and pushing/pulling changes between local and remote repositories. The document explains how to collaborate on projects hosted on GitHub using Git.
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyerNoa Harel
AppsFlyer migrated from BitBucket to GitLab for their 150 users and 680 repositories. They wanted to leave the hosted BitBucket solution due to API call limits and latency. The migration process involved converting repositories from Mercurial to Git, setting up the GitLab architecture on Amazon Web Services with an EFS file system, educating teams, and creating custom tooling like a Python script to notify Slack. Lessons learned included issues restoring backups and increasing Unicorn workers. The full technical details are available at the provided URL.
Небольшое введение в систему контроля версий Git и началу работы с ней, в частности регистрация на сервисе Bitbucket, настройка среды Visul Studio и приложение Source Tree для удобной работы с репозиториями на локальном компьютере.
Платформа: Windows.
Системы управления версиями (VCS). Знакомство с Git.Dmytro Olaresko
Данный доклад познакомит Вас с системой управления версиями файлов Git, которой пользуется Drupal-сообщество. Эта система может значительно упростить жизнь команды разработчиков, а также обезопасить Вас от потери файлов. В доклад также входит описание систем управления версиями в целом.
Видео доклада:
http://www.youtube.com/watch?v=3urk3xf79SM
3. ДЛЯ ЧЕГО: КОМАНДНАЯ РАЗРАБОТКА ПО
СТАНДАРТУ, СТАБИЛИЗАЦИЯ, CI/CD
Git Flow является методологией работы с Git. Это значит, она
определяет, какие ветки нужно создать и как производить их
слияние
git-flow является оберткой для Git. Команда git flow init является
расширением стандартной команды git init и ничего не меняет в
вашем репозитории, кроме того, что создает ветки. Есть интеграции
с IDE и GUI менеджерами репозитория
4. • Вместо использования одной ветки master, в этой модели
используется две ветки для записи истории проекта. В ветке
master хранится официальная история релиза, а ветка
develop служит в качестве интеграционной ветки для новых
функций. Также, удобно тегировать все коммиты в ветке
master номером версии
5.
6. ИНИЦИАЛИЗАЦИЯ GIT FLOW
• Первым шагом является создание ветки develop от ветки
master
• В этой ветке будет находится вся история проекта, в то
время как master содержит частичную историю
• Остальные разработчики теперь должны клонировать
центральный репозиторий и настроить отслеживание для
ветки develop
7. • Каждая новая функциональность должна разрабатываться в
отдельной ветке, которую нужно отправлять (push) в
центральный репозиторий (origin) для создания резервной
копии/для совместной работы команды
• Ветки функций создаются не на основе master, a на основе
develop. Когда работа над новой функциональностью
завершена, она вливается назад в develop
• Новый код не должен отправляться напрямую в master
9. СОЗДАНИЕ ВЕТКИ ФУНКЦИИ
Для примера создадим ветку с названием production-build
• Без использования расширений git-flow:
git checkout -b feature/production-build develop
• При использовании git-flow:
git flow feature start production-build
11. ЗАВЕРШЕНИЕ РАБОТЫ С ВЕТКОЙ
• Без использования расширений git-flow:
git checkout develop
git merge --no-ff production-build
• При использовании git-flow:
git flow feature finish production-build
12. • Когда в ветку develop уже слито достаточно нового кода для
релиза (или подходит установленная дата предрелиза), от
ветки develop создается релизная ветка, например,
release/0.3.0
• Создание данной ветки означает начало следующего цикла
релиза, в ходе которой новая функциональность уже не
добавляется, а производится только отладка багов, создание
документации и решение других задач, связанных с релизом
• Когда все готово, ветка release сливается в master, и ей
присваивается тег с версией (r0.3.0). Кроме этого, она
должна быть также слита обратно в ветку develop, в которой
с момента создания ветки релиза могли добавляться
изменения с момента создания ветки релиза
13.
14. • Использование отдельной ветки для подготовки релиза
позволяет одной команде дорабатывать текущий релиз, пока
другая команда уже работает над функциональностью для
следующего релиза
• Это также позволяет разграничить этапы разработки.
Например, можно сказать: «На этой неделе мы готовимся к
версии 1.0.0» и фактически увидеть это в структуре
репозитория
15. ВЕТКИ РЕЛИЗОВ ОСНОВАНЫ НА ВЕТКЕ DEVELOP
НОВАЯ ВЕТКА RELEASE МОЖЕТ БЫТЬ СОЗДАНА
С ИСПОЛЬЗОВАНИЕМ СЛЕДУЮЩИХ КОМАНД
• Без использования расширений git-flow:
git checkout develop
git checkout -b release/0.5.0
• При использовании git-flow:
git flow release start 0.5.0 # ещё одним параметром может быть указан [BASE], сейчас это
develop
git flow release publish 0.5.0
При желании вы можете указать [BASE] - коммит в виде его хеша sha-1, чтобы начать
релиз с него, коммит должен принадлежать ветке develop
16. • Когда релиз готов к отправке, он сливается в master и develop,
а ветка релиза удаляется (может быть сохранена при
продуктовой разработке и необходимости поддержки
нескольких релизов). Важно влить release обратно в develop,
поскольку в ветку релиза могут быть добавлены критические
обновления и они должны быть доступны в дальнейшем. Если
ваша команда делает акцент на проверку кода, этот момент
идеален для мердж-реквеста (MR, PR, Merge/Pull Request)
• Релиз помечается тегом равным его имени в ветке master. При
инициализации может быть задан префикс для тега версии
или указан в файле .git/config позже. Префикс тега не
добавляется к release ветке
17. • Без использования расширений git-flow:
git checkout develop
git merge release/0.7.0
git checkout master
git merge release/0.7.0
git tag r0.7.0
• Не забудьте отправить изменения в тегах с помощью команды:
git push --tags
• Или при использовании git-flow:
git flow release finish '0.7.0'
18. • Ветки hotfix
используются для
быстрого внесения
исправлений в
рабочую версию кода
• Ветки hotfix очень
похожи на ветки
release и feature, за
исключением того, что
они созданы от master,
а не от develop
19. • hotfix - это единственная ветка, которая должна быть
создана непосредственно от master. Как только
исправление завершено, ветка hotfix должна быть
объединена как с master, так и с develop (или с веткой
текущего релиза), а master должен быть помечен
обновленным номером версии
• Наличие специальной ветки для исправления ошибок
позволяет команде решать проблемы, не прерывая
остальную часть рабочего процесса и не ожидая
следующего цикла подготовки к релизу. Можно говорить о
ветках hotfix как об особых ветках release, которые
работают напрямую с master
20. ВЕТКА HOTFIX МОЖЕТ БЫТЬ СОЗДАНА С
ПОМОЩЬЮ СЛЕДУЮЩИХ КОМАНД
• Без использования расширений git-flow:
git checkout master
git checkout -b hotfix_branch
• Или при использовании git-flow:
git flow hotfix start hotfix_branch [BASE]
21. ВЕТКА HOTFIX ОБЪЕДИНЯЕТСЯ КАК С
MASTER, ТАК И С DEVELOP
git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -d hotfix_branch
или через git-flow:
git flow hotfix finish hotfix_branch
22. КЛЮЧЕВЫЕ ИДЕИ, КОТОРЫЕ НУЖНО
ЗАПОМНИТЬ О GIT FLOW
• Данная модель отлично подходит для организации
рабочего процесса на основе релизов
• Git-flow предлагает создание отдельной ветки для
исправлений ошибок в продуктовой среде
• Модель может быть дополнена использованием
Project-ID в названии ветки для интеграции таск-
трекера: feature/VK-342-ci
• Модель Git-flow достаточна, проста и стандартна. Для
добавления Staging и Pre-production веток
используйте модель GitLab Flow, а для упрощения и
23. ПОСЛЕДОВАТЕЛЬНОСТЬ РАБОТЫ ПРИ
ИСПОЛЬЗОВАНИИ МОДЕЛИ GIT-FLOW
1. Из master создается ветка develop
2. Из develop создаются ветки feature
3. Когда разработка новой функциональности завершена – фичеветка
объединяется с веткой develop
4. Из develop создается ветка release
5. Когда ветка релиза готова, она объединяется с develop и master
6. Если в master обнаружена проблема, из нее создается ветка hotfix
7. Как только исправление на ветке hotfix завершено, она объединяется с
develop и master
24. ПЛАГИНЫ ДЛЯ IDE
• InelliJ IDEA:
https://plugins.jetbrains.com/plu
gin/7315-git-flow-integration
• Visual Studio
Code: https://marketplace.visuals
tudio.com/items?itemName=vecto
r-of-bool.gitflow
• VS Code GUI:
https://github.com/PsykoSoldi3r/
vscode-git-flow
25. ATLASSIAN SOURCETREE
• Инициализация репозитория
• Старт ветки feature/release
• Работа по реализации фичи и
исправлений в рамках ветки
• Завершение ветки feature перед
закрытием таска
• При завершении ветки release
удаляется ветка и создаётся тег с
номером версии в ветке master
• Скачать бесплатно:
sourcetreeapp.com
choco install sourcetree
26. УСТАНОВКА ДЛЯ КОМАНДНОЙ СТРОКИ
• Linux
$ sudo apt install git-flow
• OS X
$ brew install git-flow-avh
• Windows:
входит в комплект и работает из Git bash и cmd:
gitforwindows.org
27. BONUS
Автодополнение команды git flow с помощью Tab для Bash и Zsh
• https://github.com/bobthecow/git-flow-completion
Шпаргалка по git-flow с подсказками на первое время
• https://danielkummer.github.io/git-flow-cheatsheet/index.ru_RU.html
Хуки для автоматического повышения версии и сообщения для тега
• https://github.com/jaspernbrouwer/git-flow-hooks
При подготовке презентации использовались материалы:
• https://bitworks.software/2019-03-12-gitflow-workflow.html
Презентация подготовлена для доклада в компании БИТ
• bittechno.ru