Should I have a ‘dev’ branch separate from a ‘production’ branch?

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.

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.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *