我可以在GitHub上应用Git-Flow工作流程吗

Question

I want to achieve the same workflow as outlined here in git-flow but using GitHub. However the problem seems to be that when merging with GitHub (either merge, squash or rebase) a new commit hash is added to master. This causes the permanent "develop" branch to start thinking its 1 commit behind master.

Is there some way of replicating this workflow on github? Or should i give up and use the more simple github-flow

Answer 1

Short answer : Don't merge to master using Pull Requests; instead perform the merge locally using "fast-forward", then push the branch:

git checkout master
git merge --ff-only develop
git push

Caveat : This only works if develop has every commit that master has.

Long Answer: Merges on GitHub typically occur by approving a pull request ; somebody makes a new feature branch, opens a pull request through the website, and later the merge takes place when the pull request is approved. The approval creates a merge-commit on the new branch. You want to avoid the merge-commit. But as far as I know, this is Github's default behavior, which can't be overridden. The only way to get around this would be to perform the merge using the "fast-forward" strategy locally with your tool of choice, then push the changes to the GitHub repo.

You can only fast-forward if the branch you are merging is a direct descendant of the master branch. If master has any commits that develop does not have, you won't be able to fast-forward, and a merge-commit will be created. If you're using git-flow's technique for branching "hotfix" branches from master , you may run into this issue.

Is there a benefit to doing this? Depends. You end up with a more "streamlined" repository with less commits, but you might miss out on the benefits that Pull Requests provide -- better visibility of changes to code (though in practice, code review usually happens when merging feature branches. Pull Requests merging from develop to master can feel redundant).

Answer 2

I suggest you to give up and start use your "platflorm" flow. I mean that github (as gitlab, beanstalk or bitbucket) propote its own flow. I suggest you to start to use master as develop branch (for next release) and keep all old stable releases in another branch. For example:

• branch master (5.4 development)

• branch 5.3 (the current release)

  • ... 5.3.2
  • ... 5.3.1
  • here you can tag 5.3.0

• branch 4.9 (an LTS version of old release)

  • ... 4.9.2
  • ... 4.9.1
  • here you can tag 4.9.0

Always fix in release branches and add new feature in master. If master keep retro compatibility just prepare next minor. If master broken something, ... increment the major release.