Question: Branching model and semantic-release

[Hrusikesh Panda]

I see that you're using dev branch to "store" releases (feats, fixes etc) and then using master to release the actual release when you desire. Somehow, your git history is totally linear. I was wondering what your branching/pr/merging strategy is because semantic-release makes it super hard to follow this model (accumulate releases on one branch and then release later from a different) while keeping a liner git history. I'm curious to what your flow is.

[Omar Tawfik]

@mrchief I create a PR from dev to master (see #90 for an example), and then when I merge, I choose Rebase and merge option, which rebases then adds all the commits from dev on top of the current master.

Please let me know if you have any other questions.

[Hrusikesh Panda]

That works with a minor annoyance

In your case, master is your default branch. And you have been careful to base all your PRs from dev branch. This doesn't fly so well when you start getting external PRs. Since master is your default branch, anyone sending you a PR would be based of master and not dev.

In my case, I have develop as default branch and master as stable, production branch. I do

git checkout master
git rebase develop

to merge the changes and avoid that n commits behind, x commits ahead message.

I was curious if you figured out a way of doing it purely through the GitHub UI.

[Omar Tawfik]

In my case, all new branches are created from and merged to dev, so nothing is left behind.