The git flow is not installed in your machine. Just run this command, macOS: $ brew install git-flow-avh Linux: $ apt-get install git-flow Windows: $ wget -q -O – –no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash Source git-flow cheatsheet by Daniel Kummer After successful installation run git flow init in your project and then follow the … Read more
ours and theirs is a somewhat confusing concept; exacerbated when performing a rebase: When performing a merge, ours refers to the branch you’re merging into, and theirs refers to the branch you are merging from. So if you are trying to resolve conflicts in the middle of a merge: use ours to accept changes from … Read more
We use what is called the unstable trunk development method. This was the development methodology that the creators of Subversion had in mind when they created Subversion. It’s simple and easy to implement. You do all of your development on trunk. Thus called the unstable trunk. When you get close to a release, you make … Read more
Alternatively make develop the default branch that everyone sees when visiting the project. The downside is that anyone who clones it will get an unstable branch by default but all pull requests will go to the develop branch by default too.
Something important to realize is Git branches are nothing more than a label pointing to a commit. Branching in Git is literally branching. Here’s what a repository looks like if feature branched off master when master was a commit B. A – B – C – F – H [master] \ D – E – … Read more
These steps should do the trick: Get the sha’s needed: git log <sha1> is the commit right before the merge <sha2> is the last commit on develop before you started working on the feature git checkout develop git checkout -b feature/<feature-name> git reset <sha1> –hard git checkout develop git reset <sha2> –hard Push your feature … Read more
As you mentioned, a Pull Request has only one target branch, so you won’t be able to push the hotfix to both master and develop by merging one Pull Request. I’m also surprised you mention your step #4 – merging the hotfix branch to both master and develop and push upstream – is one action. … Read more
we are having a similar setup except we have more than 300 dedicated developers, we have exactly what you described several revision we need to deliver to different customers. We have divided it so we have an initial ref like refs/heads/platformX.Y/ then we build on that So depending on what you need to do you … Read more
Looking at the source it seems that the remote feature branch is deleted only if you call git flow feature finish with -F. However, this fetches the remote before finishing the feature. From the docs: -F fetch from $ORIGIN before performing finish Otherwise you can delete the remote branch manually with: git push origin :feature/new