Think a little bit long term. You want to use master branch at release points, which is an acceptable approach. You need to copy the content of dev
into master
when that point is reached. Renaming might seem as a viable way to do this at that point, but it is not. Git is all about keeping the history and separate flows of code. Think what you will do after the rename operation. Renaming dev
to master
simply creates a master
which contains each step of development and destroys dev
. If that's your goal you can simply do all the development on master
which I believe is not what you want.
You can use master
as a summary of your project. Then dev
includes all gorry details. When you are ready to release you merge from dev
to master
(possibly with a pull request). That way master
takes all your work as a single commit.
You can see an example branching strategy that is based you a slightly more complicated version of your idea here. In this strategy master is also used only for releases. A develop
branch is where you have all the major development. Moreover feature branches, hotfix branches and release preperation branches are used. The document also shows ways to achieve all merges in pure Git, but when you get the idea you can implement it on Bitbucket more easily.