I recently set up my staging and production server environments on Heroku and everything is working great. Through Heroku, you can deploy from a Git branch – e.g.
my-feature. This got me thinking – should I have a
dev branch would essentially function as the current stage in
my-feature would be merged into
dev once it was completed. I would then deploy
dev to my staging environment and, if everything checks out, I would merge
master, and deploy
master to production.
At first glance, to me this makes sense as a workflow. Looking at the branches, it is immediately evident what is in development and what is in production. With the usual
master branch being actively developed and deployed, it’s difficult to draw the line at a glance without looking at timestamps or SHA commit hashes.
The only downside I can see is that my commit logs would basically have a merged
master commit for every deploy to production. Personally I don’t see this as a big problem, because it helps in defining the line what code is production using?.
Does having a
dev branch make sense if it is used in this way?
PS – I’m working alone on this project. I’m just curious if this makes sense as a general workflow for developers.
I feel that this is overkill for a single person working on a single web application.
I would use tags to give version numbers to versions you release to the production server. The staging server can just use the latest commit on master, whereas production uses a tag.
Have a “release” script that updates files with the new release number, commits them, then tags the commit with that release number.
Yes, this is a common workflow. The popular gitflow workflow has a separate development branch, for instance.
Different teams uses different workflows. Which stems from different team compositions. Workflows that works for open source project with large number of external contributors may not necessarily work for internal company project or for personal project. There is no one good workflow that works for everybody.