0

At work we have a git flow where - developers correct a given defect in the development branch - then they have to 'put'(*) their correction in the integ branch - this integ branch must be accessible to our customers because they want to check out our code and recompile it themselves

The customer wants a clean branch, ideally with a commit per corrected defect.

But our developers might deliver their work in several commits (one defect corrected by several commits in the development branch)

If we simply merge the development branch into the integ branch, the client will see in the history all the atomic commits performed by the development guys, which shall be avoided.

Question related to (*): How can we clean the branch for the customer? - without imposing a "one commit per defect" rule to the developer - ideally without cherry-picking and squashing the atomic commits corresponding to each defect in the integ branch (because cherry-picking duplicates the commits)

Edit: I don't want to perform a git rebase interactive and squash the commits from the development branch. It's the developer branch and they split the commits for a good reason from the developer point of view (maybe technically or logically it makes sense to create several commits). From the client point of view, they don't care about the fact that a defect was corrected by several commits, they want a clean history on THEIR branch

Willem Van Onsem
  • 443,496
  • 30
  • 428
  • 555
facewindu
  • 705
  • 3
  • 11
  • 31
  • 1
    possible duplicate of [How can I merge two commits into one?](http://stackoverflow.com/questions/2563632/how-can-i-merge-two-commits-into-one) – John Apr 11 '15 at 20:17
  • I don't approve rewriting history, how about using tags instead? Create a tag for very resolved issue, so they can checkout the corresponding tag. – Reactormonk Apr 11 '15 at 21:07
  • By using tags, the client won't see any history at all. They want to see a clean history (ie a history with one commit per defect corrected) instead of the full, real, technical history – facewindu Apr 11 '15 at 21:14
  • 3
    You confuse a clean history with something your customer wants to see. Clean history is what your developers create, your customer wants to see commits related to the same defect squashed. – Palec Apr 11 '15 at 21:44
  • 1
    If the customer needs to really have the history with squashed commits, you have to create it, e.g. when interactively rebasing. Most probably this is not the case and your customer needs just a different view of the branch. – Palec Apr 11 '15 at 21:46
  • Yes I agree. My original explanation wasn't accurate enough, but that is the point. How can we make both things live together? A clean history (from dev point of view) might not be what the customer wants. I suppose I could push the integ branch to a remote repo and rework it there, without touching the developers repo – facewindu Apr 11 '15 at 21:50
  • Each developer has his own repo and pushes the changes into a central repo. The customer cloned a copy of the central repo and pulls changes. (If this is not the setup, correct me.) The customer can get only a piece of history that already exists in the central repo. If they don’t want to pull the original history, you have to duplicate the history your developers create to create the squashed one. If pulling the original history is OK but a different view is needed, just take care of the display. This is a fundamental dilemma and the customer must say, why they need to see the history at all. – Palec Apr 11 '15 at 22:00
  • 1
    So, why does the customer need the squashed history? What do they want to do with the history? Do they need just a changelog, or do they actively work with the history you provide? – Palec Apr 11 '15 at 22:03
  • They only need access to the history to generate a changelog with their own format /display. And they need access to each tagged commits to recompile it as well – facewindu Apr 12 '15 at 05:57

2 Answers2

2

You could show only the merges into integ with git log --merges.

Graham Perks
  • 23,007
  • 8
  • 61
  • 83
  • Well yeah it could help. The problem with my initial approach is that the client has access to the integ branch and he could run your 'git log --merges' but he also could see anything he wants in the repo. – facewindu Apr 11 '15 at 21:38
  • What if I push the integ branch into a remote repository? Will the commits in the development branch be seen as well in the remote repo? – facewindu Apr 11 '15 at 21:40
2

If I'm reading it right you just need to include the --no-ff flag (no fast forward) when you merge from dev branch. Your fixes will be merged from the dev branch into the integ branch as a single commit containing all the changes.

There is quite a well known blog post, A successful Git branching model, from a few years back that advocates this method of working.

Chilledrat
  • 2,593
  • 3
  • 28
  • 38
  • I remember reading this article as well. The problem is that whatever the branching model, when develop is merged into release branch, or when feature X is merged into develop branch (even with --no-ff) everyone that has access to the repo can see all the history. – facewindu Apr 12 '15 at 18:03
  • I need a way to publish a 'filtered' view of my history to the customer's repository – facewindu Apr 12 '15 at 18:03
  • 1
    You seem to be asking for something different than your original question. You ask "The customer wants a clean branch, ideally with a commit per corrected defect." and that is what merging with --no-ff will give you. Combined with the answer from @Graham you can also get the history you want. Of course, as you point out, if they have access to the same repo as you (or a clone) then yes, they will have access to the whole history. That is a strength of git so perhaps your customers just need educating? – Chilledrat Apr 12 '15 at 19:01
  • 1
    Yes that's a nice summary. I will try to talk them into doing that – facewindu Apr 13 '15 at 06:06