-
Suggestion
-
Resolution: Fixed
-
None
-
None
Background
Clean History?
In our team we want a git version history which contains one commit for each Jira ID, i.e. one commit for each feature (further referred to as clean history..).
Collaboration on Changes
When a developer wants to make a change to the main line code the developer will push a new branch to the stash server with the Jira ID of the feature. The developer then goes to the stash interface and creates a pull request for this branch.
Another person on the team will review the code. Ideally there will be some discussion about the change and some improvements will be suggested.
Iteration on Changes
I am going to explain two possible workflows on iteration on changes and explain the issue with each.
Workflow 1
Taking on board the suggested improvements from the review process, the developer makes a new commit and pushes this commit to the same branch. Thus creating a second commit on that branch.
This process continues until all parties are happy with the change and the branch is merged with the mainline.
Issue
When the merge happens, all of the individual commits are visible on the mainline branch plus one 'merge' commit i.e. we don't have one commit for each feature.
Workflow 2
Taking on board the suggested improvements, the developer amends the existing commit and then force pushes the change to the existing branch on stash.
This process continues until all parties are happy with the change and the branch is merged with the mainline.
Issue
When the developer does a force, he/she runs the risk of accidentally overwriting another branch or pushing a corrupted history.
Summary
We need some way to iterate on changes during the review process while maintaining a clean history. On top of this we do not want to use the --force flag in git because it could corrupt branches on the stash server.