8

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. master or my-feature. This got me thinking - should I have a dev branch?

The dev branch would essentially function as the current stage in development; branch 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 dev into 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 dev with 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.

2 Answers 2

10

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.

2
  • I agree with this. Tags are the built-in way to manage deployments, whereas branches have the full power for concurrent development, and whenever possible, you should not overkill. Just develop on master, you will have everything you need.
    – Diane M
    Commented Jun 13, 2016 at 11:25
  • +1. Tags are much simpler to manage than branches, and more than adequate for this job. The only reason you might need a production branch is if you decide you need to apply hotfixes for bugs in production while working on long-term development tasks, but this is unlikely to crop up for a single developer/small team. Stay agile by keeping your master branch deployable at all times, is my usual suggestion.
    – Jules
    Commented Jun 13, 2016 at 12:21
5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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