Git Resources • GitHub Training. A successful Git branching model » nvie.com. Note of reflection (March 5, 2020)This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.This is not the class of software that I had in mind when I wrote the blog post 10 years ago.
Why git? ¶ For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. The main branches ¶ develop. Why aren't you using git-flow? If you need tagged and versioned releases, you can use git-flow’s release branches to start a new branch when you’re ready to deploy a new version to production. Like everything else in git-flow, you don’t have to use release branches if you don’t want to. Prefer to manually git merge --no-ff develop into master without tagging? No problem. However, if you’re working on a versioned API or library, release branches might be really useful, and they work exactly like you’d expect: $ git flow release start 0.1.0 Switched to a new branch 'release/0.1.0' Summary of actions: - A new branch 'release/0.1.0' was created, based on 'develop' - You are now on branch 'release/0.1.0' Follow-up actions: - Bump the version number now!
- Start committing last-minute fixes in preparing your release - When done, run: git flow release finish '0.1.0' Bump the version number and do everything that’s required to release your project in the release branch. Git-cherry-pick. Git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>… git cherry-pick --continue git cherry-pick --quit git cherry-pick --abort Given one or more existing commits, apply the change each one introduces, recording a new commit for each.
This requires your working tree to be clean (no modifications from the HEAD commit). When it is not obvious how to apply a change, the following happens: The current branch and HEAD pointer stay at the last commit successfully made. See git-merge(1) for some hints on resolving such conflicts. git cherry-pick master Apply the change introduced by the commit at the tip of the master branch and create a new commit with this change. git cherry-pick ..mastergit cherry-pick ^HEAD master Apply the changes introduced by all commits that are ancestors of master but not of HEAD to produce new commits. git cherry-pick maint next ^mastergit cherry-pick maint master..next git cherry-pick master~4 master~2 git cherry-pick -n master~1 next.
Git/GitHub. Why aren't you using git-flow? Top 10 Git Tutorials for Beginners.