Menu
I see some people use branch named dev beside master for development environment. Even they use feature branch, they say that having dev branch is better. I actually didn't hear suitable answer of why. Even there is dev branch, works must still be done before pushing it. (http://nvie.com/posts/a-successful-git-branching-model/)
I really don't understand. Why do I need to have dev branch after all.
Thats all. This flow fixes everything for me. I don't see any reason to have dev branch.
What case do I miss? What is the problem with using master as a development environment? Which cases you use dev branch for if you do?
607
dev branch may be useful when there are several teams on the same project, but it's not mandatory at all, it must fit your needs. Git allows you to have whatever branch structure you want. If your workflow works for you, it's the right one to use.
Instead of a single main branch, this workflow uses two branches to record the history of the project. The main branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the main branch with a version number.
Often, the version that will eventually become the next major version is called the development branch. However, there is often more than one subsequent version of the software under development at a given time.
There is no need to create a branch per user. I would even go so far as to say that it would be counterproductive. If you are working on the same feature, you will probably want to get each other's changes, by pulling and merging. Creating branches per user is redundant and will complicate things unnecessarily.
Master branch which is your a working branch of your production, it has to be bug free, well tested and contain stable code. Development branch however can contain issues and other complexities.
Let's say, you have committed your development from dev server on master branch, you pull on staging and unfortunately it creates issue w.r.t. staging server setup, you go back to development and fix it. In between this, client asks for urgent hotfix in which you want to push some changes urgently on live server. This reverting and changing files again can be a crazy tough job in such situations.
Instead, if you keep master branch only for live, dev branch for development environment, stage branch for testing and staging environment.
You develop on dev branch, push it to staging, if works merge it with staging branch, if not, go back to dev, fix it and then push again. If stage is all set, you pull that to live. Check for some time. If there are issues, immediately checkout to master, fix it, push stage again, Once all set, merge with master and checkout in master as current branch.
In this case, if client asks for urgent changes on live, you checkout to master branch on development server, create a new branch from it (never change directly into master), fix it, push on stage and then push on live. In this hurry, if fix goes wrong, you can always checkout to master and if correct merge it with master.
In this case, your dev branch on development server is untouched which is easier to commence your development again.
144
I would advise that you use a dev branch.
I typically follow the following rule of thumb:
Small changes in the code go on "development" branch.
Major features that several people will be working on go on their own "feature" branch.
Small bug fixes on the master branch go on their own branch called "hot fix" and are merged back in the master branch right away.
Everything at the end gets merged into the master. Master should be considered your release branch that goes out to the public. It should be code that has been tested and is considered stable.
Explained more in detail here: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
