1

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.

Community
  • 1
  • 1
Dror
  • 12,174
  • 21
  • 90
  • 160
  • 2
    Why do you have to do this? – BroiSatse Oct 22 '14 at 15:28
  • First why do you need --no-ff? and second, what is wrong about creating a new branch for a new feautre? that should be the way to go. If you call your branch with a name regarding the task you will see that it makes sense – iberbeu Oct 22 '14 at 15:30
  • I must have clean merges into master. All the development is carried out in `dev`. I branch from `dev` for feature, then merge back to `dev`. When I'm ready, I merge to `master`. I have to keep the merges visible in the history. – Dror Oct 22 '14 at 15:35
  • @Dror - but why do you need to destroy the dev branch and recreate it? What you have descirbed is a typical gitflow, have a read: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow. No branch removing is required. – BroiSatse Oct 22 '14 at 15:36
  • But why? Are there any non-technical reasons to do it? If you want to mark place, where branch dev was merged into master history, then maybe tags are better solution? – Patryk Obara Oct 22 '14 at 15:39
  • 2
    Personally I like the --no-ff option. As the others mention, I don't see why you are deleting and recreating dev though - you should be able to just continue on with it. – Andrew C Oct 22 '14 at 15:45
  • Do you mean "rest", or "reset"? –  Oct 22 '14 at 17:13
  • @AndrewC: See my update. Simply continuing the development on `dev` yields a messy graph. – Dror Oct 23 '14 at 08:20
  • You could certainly argue aesthetics for that particular case. Given enough time, developers, and branches though and it probably doesn't make a difference in the long run. – Andrew C Oct 23 '14 at 15:03
  • Are you rebasing *dev* onto *master* before merging and using `git-svn rebase`? I don't understand why your history keeps re-merging the same commits, and I feel like there's something in your workflow that's not in your question. – Todd A. Jacobs Oct 25 '14 at 14:30

2 Answers2

3

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
Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
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.

mgarciaisaia
  • 14,521
  • 8
  • 57
  • 81