0

Our product is released every month. I'm looking at popular git flows like the ones in the official git site or Atlassian's. On a high level it is recommended to:

  1. Develop in develop branch
  2. Create a release branch
  3. Test and prepare
  4. Pull request to master

While I understand the need for the release prep step, I'm worried that the pull request to master will be huge (1 month of development) - does it mean that these types of pull requests are automatically approved and merged?

Any better flow to suggest?

2

If you arrange the workflow such that changes to develop and release branches are only allowed through a peer-reviewed pull-request, then the pull request to master will indeed be massive, but it doesn't need to be reviewed as carefully.

As all changes in the pull-request to master should have been reviewed at least once before, it would be sufficient to do a few spot-checks to see if the process needs to be adjusted (i.e. do you see any changes that were not part of a review/pull-request before).

0

Work on a master branch for your regular work. When you develop a feature consider a feature branch, when its clear that you will do other things inbetween before the feature is finished.

For commits which produce code that does not compile (or has other obvious errors) use a local branch, which is never pushed. merge commits later and rebase them until it looks clean, than either rebase it onto master or as a feature branch you merge into master.

For a release, create a release commit, i.e. changing the version number in the readme, changing the ChangeLog entry from 1.1.0-dev () to 1.1.0 (2017-09-22) and similar. commit it for example with the commit message "version 1.1.0".

If you plan to support it parallel to newer versions, create a branch for v1.1.0, where you cherry-pick the bugfixes from master branch. For 1.1.1 you then create a correponding version 1.1.1 commit and tag in the branch. Leave old branches as they are. You never know when you will backport a very important fix for a customer who really wants to use the old version. You may consider to add a commit indicating the lack of support when a old version is no longer maintained. But a hint in the readme on the homepage and master branch may be enough.

Good versions never change. If your version 1.1.0 is broken, release a working 1.1.1 and just remove the broken packages for 1.1.0 from your website. Some sites like python pypi will not even let you upload a new package with the same version number, because people would never be able to tell if they have the broken or the working version.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.