Git workflow to audit commits without rewriting history

Question

I am working with a developer that is new to git, and I would like to setup a git workflow that would let me auditing the commits made by this developer (and possibly reject them) without forcing him to rebase his work (which is error prone for new users).

Here is the scenario :

• the master branch contains only audited code
• devel branch is created by forking master branch
• a developer is working on the devel branch and push his code for me to audit
• I detect some issues with his code, so I ask him to make more commits on devel branch to fix the issue
• Once I'm happy with the code, I cherry-pick (or merge with squash) the developers commits on the master branch, add my own comments and mark the commit as authored by the developer
• The developer merge back the master branch into his devel branch

Here is a visual illustration of this scenario :

After this sequence, how can I be 100% sure that mistakes made by the developer during the "make mistakes / redo" sequence will not show up again when the developer will push his devel branch again after some other commits ?

The best solution would be to ask the developer to rebase his devel branch against the master one, but this is a hard task to new git users.

If this workflow is wrong in any way, please suggest me another where I would be able to audit the commits before merging them into the master branch.

EDIT

A friend suggested me a direction that looks promising : the --fixup option when doing commit.

--fixup=<commit>

Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase for details.

This option could be used by the developer to properly mark his second and third commits as a fix for his first one. A good solution to explore...

Answer 1

Remark 1: By trying to turn the separated commits on devel into a single commit on master, you are rewriting history. I see the point in trying to keep a clean, linear history on master, however a less linear history with merges would be more easily integrated with git basic commands.

Remark 2: If your workflow explicitly includes members which are not familiar with the basic tools you use to share code, you should live with the consequences. At some point, I think the developer should learn git.

Here are two suggestions :

1. Drop the linear history on master, and "validate" the changes by running, from master :

   git merge --no-ff devel
   

   This is the most straightforward way to inform git that the modifications on devel are taken into account on master.

2. Do the merge with devel yourself, and have your developer pull the modifications from origin/devel.
   If the single commit on master really only consists in squashing the commits on devel, this shouldn't trigger any conflicts -- the merge commit master->devel should introduce 0 modifications.
   If you have actually modified the squashed commit, and the developer can have local modifications of his own, you have to face the possibility of triggering conflicts on his side anyway ...

Answer 2

If you're going to just squash the dev branch instead of merging it normally, it's not a good idea to then merge that squashed commit back into the dev branch, because then you'll get a ton of confusing conflicts, because git thinks you're applying new code, when in fact it's actually the same code.

It would be better to either just do a simple merge into master, then a simple merge back into devel, or otherwise throw-away the devel branch and make a new one off of the most recent commit of master. As long as the code that you merge into master is "good", according to you, then you probably won't get any regressions.

On the other hand, if you go with your original plan of merging in squashed commits back into devel, that will increase your chances of a regression occurring, because of the confusing conflicts.

Update

I deleted parts of my answer above because I actually just tested doing the squash commit on master and then immediately merging it back into devel, and it didn't cause any conflicts, so that part of my answer was incorrect.

I turned this into answer into a community wiki because it still contains a lot of information about the problem in the comments.