6

I'm using Git for code versioning.

I have a development branch on which i'm doing all the dirty development.

Every time I publish a production version to the world, I want to put it under my master branch.

The problem is that whenever I merge development and master, master receive all development history.

I want to keep everything clean so the branches will look like this:

development

"init commit"

"developing"

"Version 1.0"

"bug fixing"

"bug fixing"

"Version 1.1"

master

"Version 1.0"

"Version 1.1"

Is it possible? and if so, how ?

UPDATE I tried to use Gauthier answer but it doesn't worked as I wanted.

The steps I took was as followed: 1. created an init commit in master 2. switched to development. 3. added few commits to development. 4. checkout master 5. git merge development --no-ff

The merge was successful but when i'm looking on high level at my repository, I see that in my master branch I have all the history of the development branch, while I wanted to have only init-----version 1.0.

This is screen shots of how it looks:

development branch: enter image description here

master branch: enter image description here

Gauthier
  • 40,309
  • 11
  • 63
  • 97
Asaf Nevo
  • 11,338
  • 23
  • 79
  • 154

3 Answers3

4

Do you know about --no-ff?

You currently have:

o init commit
|
o developing
| 
o Version 1.0
|
o bug fixing
|
o bug fixing
|
o Version 1.1
|
o Version 1.0
|
o Version 1.1  - development - master

(time going downwards as in your example, instead of what git log and gitk do)

My guess is that you are unhappy with master because everything gets directly there, at the same level.

If you would be happy with:

o init commit
|\
| o developing
|/ 
o Merge branch 'development' - Version 1.0
|\
| o bug fixing
| |
| o bug fixing
|/
o Merge branch 'development' - Version 1.1 - development - master

then when you want to release what you have in development, merge to master with --no-ff, and tag:

$ git checkout master
$ git merge development --no-ff
$ git tag "v1.0"

Note that you should consider working in branches named after the feature you are working on, rather than everything in development. This would lead to better merge messages, such as "Merge branch 'killer_feature'". Maybe that's what you have in development already, in that case, sorry.

Gauthier
  • 40,309
  • 11
  • 63
  • 97
  • That exactly what I want to achieve. What does --no-ff mean? – Asaf Nevo Apr 30 '15 at 13:48
  • @AsafNevo : `--no-ff` means no fast forward. Fast forward is a type of merge that, if the branch you merge *to* (master) has no new commit since the creation of the branch you want to merge (development), just moves the current branch to the last commit of the merged branch. It does not create any merge commit. In effect, it is a merge (all changes are there), but the fact that you don't have a merge commit kind of hides the fact that you had a branch. I don't like it either, I like to show which commits belonged together in a branch. Lookup fast-forward merge in `man git merge`. – Gauthier Apr 30 '15 at 13:56
  • could you please look at my update in the questions including the screenshots? I did what you said, but it didn't do it as I thought it will do, and in fact it looks like a regular merge – Asaf Nevo May 07 '15 at 11:00
  • Showing the `master` branch will always show you all the commits needed to reach to the commit. `git` does not remember in which branch commits were created. Branches in `git` are nothing more than a reference to a commit. In turn, commits have reference to their parent commit (several of them for merge commits). When you show `master`, it begins with the commit `master` points to, then the parent(s) of this commit, and so on. Why is it a problem that the commits that were created in development show up? – Gauthier May 07 '15 at 11:58
  • @AsafNevo At least the branch commits are visually grouped in your master screenshot, thanks to `--no-ff`. – Gauthier May 07 '15 at 12:01
  • but my propose was that the master branch will be clean.. currently it holds all the history of the development branch – Asaf Nevo May 07 '15 at 12:38
  • Then you can `--squash` while merging, but again: why is it a problem? The fine granularity of commits that `git` allows is a good thing! – Gauthier May 07 '15 at 12:40
  • its not really a problem. maybe its more of an OCD :) I just wanted (if possible) to have a clean master branch holding only the distribution versions while the development holds the messy commits of the development process – Asaf Nevo May 07 '15 at 12:56
0

This is not possible in the same repository. All branches share the same common history. Git branch is not a separate copy of your commits, but a lightweight solution to re-use as much as possible of the existing data.

Solutions:

  • However, it is still possible to create new "clean" commit for the master, which squeezes many "dirty" development commits. See this solution.

  • If you want to have a "clean" repository, consider creating another, public, repository. You can just copy over each new release and submit a commit for it.

Mykhaylo Kopytonenko
  • 923
  • 7
  • 15
0

First of all let me say that you should not do this :) you can use --squash parameter of git merge and re-commit the changes in one commit with the message you want. At this point you will have to reset --hard your development branch to master branch to avoid merging the same changes next time you merge development branch into master branch.

Second approach would be to avoid writing commit msgs like "Make changes to the code" or squash your temporary commits once the feature/work is complete on development branch and then merge to master.

P.S. git log master --merges will give you the history of master the way you want it and you would not lose your git history (given that your merge messages are ok and you use --no-ff when merging)

Lyudmil Nenov
  • 247
  • 2
  • 6