Lately I've been working on project and created beside master, a dev branch. I've been pushing new commits of 'checkpoints' (just saving my work) and finished features. After finished feature I always merge with master.
My workflow is:
1) git push origin dev with_some_commit // few times
2) git checkout master
3) git merge dev
4) git push origin master
So for me a typical flow (till now).
I was wondering recently if this type of workflow is correct. Till now I imagine my workflow as:
// before merge:
---o---o---o---> master
\---o---o--->dev
// after a marge:
---o---o---o-------------> master
\---o---o--/
// and continue on dev:
---o---o---o----------------> master
\---o---o--/ \---o---> dev
Well now I'm not so sure of this // and continue on dev thing.
I wonder if really after first merge, if I continue to push on merged branch it will split commits. The question is: how does it really work ?
Another thing is merging those commits. Should merging be done only with finished features commits or finished features + all the in-between checkpoint commits too ? If second option, how to split those commits ?
There are several branching strategies that are popular. Atlassian (the team behind Jira and BitBucket) has a good guide on Gitflow Workflow, a flavour of git flow - one of the most popular strategies.
Long lived feature branches are generally discouraged. Branches are cheap in git and with the exception of the special ones (develop, master, releases branches) should not reused. Feature (aka topic) branches should be short lived.