Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-3993

Enable the ability to iterate on changes during the review process while maintaining "clean history"

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Fixed
    • None
    • Pull Requests
    • None
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      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.

              Unassigned Unassigned
              a12e3b8c6348 Brian Fletcher
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: