# gitflow

Published articles for gitflow.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## GitFlow with GitHub

DevFeed: [GitFlow with GitHub](<https://devfeed.tech/articles/gitflow-with-github-23100.md>)

Original publisher: [Read original article](<https://medium.com/android-news/gitflow-with-github-c675aa4f606a?source=rss----8fca399d4de---4>)

Author: Maciej Najbar

Published: 2020-04-27T17:43:02Z

Content type: article

Language: en

Sources: [Android & Tech News -- Medium](<https://devfeed.tech/sources/android-tech-news-medium.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [continuous-delivery](<https://devfeed.tech/tags/continuous-delivery.md>), [git](<https://devfeed.tech/tags/git.md>), [gitflow](<https://devfeed.tech/tags/gitflow.md>), [github](<https://devfeed.tech/tags/github.md>), [gitlab](<https://devfeed.tech/tags/gitlab.md>), [programming](<https://devfeed.tech/tags/programming.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [testing](<https://devfeed.tech/tags/testing.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

### AI overview

An overview of GitFlow branch management, including master and develop branches, feature, release, and hotfix branches, and the challenges of resolving conflicts.

### Source excerpt

Why we have to choose between safety and tidiness? https://nvie.com/posts/a-successful-git-branching-model/ Quick note before I begin. GitFlow, was first published by Vincent Driessen in 2010. He suggests a simpler workflow -- GitHub Flow -- for the teams that do not have to support multiple versions at the same time. For further reading see the post from the author himself. Most of the teams around the world have worked, work or will work with GitFlow. A good understanding of branch management and conflicts resolution can save a lot of trouble. The latter is the topic that I will focus the most in this article. tl;drLong living branches master -- this is where stable production ready code lands. No direct commits are allowed. If you want to configure Continuous Delivery for your project, master branch is exactly the place (read how to hook on commits). Each change on this branch must be tagged with version number. develop -- this is a construction area. All new features are merged to it. This branch should be buildable all the time. If it doesn't (for any reasons), fix it asap. Special branches Feature branch - branches off from develop - merges to develop - naming: anything but master, develop, release or hotfix; most commonly devName/JiraTicketNo Feature branch Release branch - branches off from develop - merges to master and develop - naming: release, rc Release branch Hotfix branch - branches off from master - merges to master and develop or release (if exists) - naming: hotfix Hotfix branchConflicts This is the most important topic to cover. They will occur eventually -- even in one-man projects; that's right, I work with a great developer who did do just that 🙂 Anyway, I want to focus mostly on it because it's a very marshy ground and can bring tragic effects to the project. Perfect flow? Never happen! I know the feature branch may look like it doesn't follow GitFlow rules, but let me explain it. Plans are useless, but planning is indispensable. -- Dwight Eisenhowe