Git Pull Request Iteration Changes 

Problem statement: Git is a popular tool for software developers to share and review code before committing it to the mainline source code repository.  Collaborators often exchange feedback and comments on a web user interface by creating a pull-request branch that captures the changes to the source branch. As it accrues the feedback and consequent modifications, it gives an opportunity for reviewers to finalize and settle on the changes before it is merged to the target branch. This change log is independent of the source and the target branch because both can be modified while the change capture is a passive recorder of those iterations. It happens to be called a pull request because every change made to the source branch is pulled as an iteration. The problem is that when the iterations increase to a large number, the updates made to the pull request become a sore point for the reviewers as they cannot see all the modifications on the latest revision. If the pull request iteration changes could be coalesced into fewer iterations, it becomes easier to follow and looks cleaner in retrospect. The purpose of this document is to find ways to do so, which by design was independent of the requestor and the reviewer. 

Solution: A pull-request workflow consists of the following:  

Step 1. Pull the changes to your local machine. 

Step 2. Create a "branch” version 

Step 3. Commit the changes 

Step 4. Push the changes to a remote branch 

Step 5. Open a pull-request between the source and the target branch. 

Step 6.  Receive and make iterations for changes desired. 

Step 7. Complete the pull-request by merging the final iteration to the master. 

When the iterations for Step 6 and Step 7 grow to a large number, a straightforward way to reduce iterations is to close one pull-request and then start another but developers and collaborators will need to track multiple pull-requests. Since this presents a moving target to complete, it would be preferable to modify a pull-request in place.  

Git REST API offers an option to retrieve the pull-request revisions but not a way to edit them. For example, we have GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/iterations/{iterationId}/changes?api-version=5.1 that gives the changes between two iterations but this is not something we can edit. 

The git SDK also offers a similar construct to view the GitPullRequestIterationChanges but these are not modifiable. 

Instead, we can run the following commands: 

cd /my/fork 

git checkout master  

git commit –va –m “Coalescing PR comments” 

git push 

If the commits need to be coalesced, this can be done with the git pull –rebase command. The squash option is for merge. Bringing in changes from the master can be done either via rebase or merge and depending on the case, this can mean accepting HEAD revision for former or TAIL revision for latter. 

The git log –first-parent can help view only the merge commit in the log. 

If the pull request is being created from a fork, the pull-request author can grant permissions at the time of pull-request creation to allow contributors to upstream repositories to make commits to the pull requests compare branch. 

Reference: 

1. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork 

2. https://stackoverflow.com/questions/7947322/preferred-github-workflow-for-updating-a-pull-request-after-code-review 

3. https://stackoverflow.com/questions/16748115/how-to-modify-github-pull-request