What is a smarter way to “reset” a dev branch in G

Question

I have a master and dev branches. Whenever I merge dev into master I have to use the --no-ff (no fast-forward) method. What I do at the moment, after merging:

• delete dev
• start a new dev branch from master

This allows me to continue the development on dev after the merge. Is there a smarter/shorter way to do it?

Edit:

Simply continuing to commit to dev and merge to master yields the following graph:

git log --oneline --graph --branches 
*   62d400f Second Merge branch 'dev'
|\  
| * 86cd761 Continue 2 dev after merge
| * b10e96b Continue dev after merge
* |   04dcd00 Merge branch 'dev'
|\ \  
| |/  
| * 80d5577 Continue dev
| * 7119020 Started to dev file
|/  
* 05350a5 Updated the file
* 9e70af0 Initial commit

However, if I delete dev and then branch again from master, I can have the following graph:

*   c39c881 Third Merge branch 'dev'
|\  
| * cab5dc5 Back on (new) dev
|/  
*   62d400f Second Merge branch 'dev'
|\  
| * 86cd761 Continue 2 dev after merge
| * b10e96b Continue dev after merge
* |   04dcd00 Merge branch 'dev'
|\ \  
| |/  
| * 80d5577 Continue dev
| * 7119020 Started to dev file
|/  
* 05350a5 Updated the file
* 9e70af0 Initial commit

Correct me if I'm wrong, but this looks cleaner, isn't it? That's why I, naively, delete and re-branch from master.

As for why I have this approach in the first place: my master is basically an SVN where I'm allowed only certain commit messages (and thus limited number of commits). So I develop on dev and when I'm ready I merge to master and leave the proper commit message.

Context:

I use the workflow described in this answer. I somehow realized that I have to delete dev and re-branch from master after I push the changes to SVN.

Answer 1

To avoid having to delete dev and re-create if from master, you can simply git reset --hard master while on your dev branch.

Answer 2

TL;DR

In Git, a branch named dev that points to a given commit (e.g. cf2308e) is still the same branch, even if you delete it and re-create it. The branch name holds the reference to a commit; Git doesn't carry around any other branch-related history, so what you're doing isn't inherently useful to Git or to you.

Continue After Merging

I have a master and dev branches. Whenever I merge dev into master I have to use the --no-ff (no fast forward) method.

Typically one does this when they want to force a merge commit rather than a fast-forward. Some shops like to do this to track merges from a branch within commit messages, since Git commits don't actually carry any branch information. In Git, branch membership is inferred from the ancestry of the commits, rather than stored as explicit data like it is in some other distributed version control systems.

However, there's no useful reason to actually delete the merged branch to "reset dev." You can continue developing on the dev branch, and Git will be smart enough not to re-merge the same commits the next time you merge with master.

Deleting and recreating dev doesn't really buy you anything if you're simply going to branch off the tip of master again. Since you aren't using topic branches with useful names, and you aren't doing squashed commits, my advice is to simply continue forward on dev after merging with master.

Resetting a Branch

The only real use case for doing this is if you are merging something other than the tip of the dev branch. In that case, you may want to discard anything from dev that isn't already on master. If that's the case:

git checkout master
git merge --no-ff <some_commit>

git checkout dev
git reset --hard master
git push --force origin dev

Note that if you rewind the tip of your branch, you'll likely have to force-push in order to reset the branch pointer on your remote. Rewinding will also force anyone pulling from you, or from a blessed repository, to re-clone or perform a forced reset of the dev branch too. For example:

git checkout dev
git fetch --all
git reset --hard origin/dev