[testcase notes] #20: Pull request, inside one repo, between different branches

[dorawyy]

abstract: PR2 (head branch) --- send a pull request---> PR1 (base branch) inside one repo

Scenario abstract

--> Different branches inside one repo, only Alice commits

• PR2 branch (Pull-Request-2 branch) was derived from PR1 branch (Pull-Request-1 branch)
• Alice and Bob worked on the same repo, Alice(PR2 branch), Bob(PR1 branch)
• Alice made commits on PR2 branch locally
• Alice git push origin PR2
• Bob made no change on PR1
• Alice made a pull request to Bob: FROM: repo1, PR2 --> TO: repo1, PR1
• What would Bob do and meet?
  • What if he merge directly
  • What if he squash commits then merge?
  • What if he rebase then merge?

( in the scratch below, replace F1 with PR1, replace F2 with PR2)

Results:

• Option1: When create a merge commit,
  • no conflict
  • all commits on head branch (PR2 in this case) are applied directly to the base branch (PR1 in this case)
  • also a pull request merge commit is created;
  • no effect on the head branch
• Option2: When squash commits and merge,
  • all commits on head branch (PR2 in this case) are squashed into a single commit
  • then the new commit gets applied back to the base branch (PR1 in this case).
  • the squashed new commit is a normal commit (not merge)
  • no merge commit created.
  • the two branch diverges after the pull request
  • no effect on the head branch
• Option3: When rebase and merge,
  • rebase all ( let's say, n commits of head branch (PR2 in this case) to base branch (PR1 in this case) --> But does not change commits on the head branch (PR2 in this case)
  • all n refined (SHA changed) commits are reapplied to the base branch (PR1 in this case)
  • no merge commit created ( as rebasing first)
  • the two branch diverges after the pull request
  • no effect on the head branch ( did not get rebased, SHA still the same as previous time )

Data could be explored:

• Option1: When create a merge commit
  • a merge commit about the pull request will be created
  • no sign for conflict
• Option2: When create a merge commit
  • nothing left
• Option3: When rebase and merge
  • if no conflict, would see commits on both branches with same commit info but different SHA
  • (not sure, but should be) disabled if rebasing conflicts

Detailed steps:

Step0: prep

• create PR1 branch from master branch
• createtest20 as test file on PR1
• create PR2 branch from PR1 branch

# create PR1
git checkout master

git checkout -b PR1
touch test20
# edit test20

git add test20
git commit -m "testcase20: startpoint (create file test20 on PR1 branch)"
git push origin PR1

# create branch PR2
git checkout -b PR2
git push origin PR2

##### Now both PR1 and PR2 are set, at the same commit, we can start the test case

Content of test20:

Startpoint - project tree:

Step1: Alice committed on PR2 , pushed back to remote

git checkout PR2
vim test20
# edit test20, line 20

git add test20
git commit -m "PR2: edited the file test 20, line 20"

git push origin PR2

The edit on the file test20 is:

After git push origin PR2, here is the project status:

Step2: Bob made no change on PR1

Nothing to do in this step
Project status after this step (same as status of step1):

Step3: Alice made a pull request to merge PR1 and PR2

This is the page that Alice will see when she create a new pull request:

Observation1:

• in this pull request, there is only 1 commit, thus the default pull request title is the same as the commit message

• However, Alice modified it to something more meaningful; Alice also attached detailed information about the pull request

Observation2:

• Alice can add more commits by pushing to the PR2 branch on dorawyy/git-merge-conflicts-test.

Step4: Alice work is done, now Bob's turn. He needs to decide what to do with the pull request.

Here are all the options he has:

Also, here is command line instructions, telling us how to make a manual merge

---

Option1: Create a merge commit

All commits from this branch (PR2 in this case) will be added to the base branch via a merge commit.

• If Bob chooses to Create a merge commit, this is the page he will see, to create a `pull request merge commit:

• Here is the info input by Bob, in the merge commit:

• Then, the merge is done:

Option1 Result

• nothing changed on PR2 branch
• all commits on PR2 branch that are merged (only 45c39f0 in this test case), are merged back to PR1 branch
• also, the merge of the pull request explicit created a merge commit(d8cae67) (though actually fast-forward merging)

Here is commits history of PR2

Here is commits history of PR1

Note: the newly created commit is a merge commit, telling from the history here:

Pull PR1 and PR2 to local again, merge, then push back to remote

• sync PR1 and origin/PR1, sync PR2 and origin/PR2

git checkout PR2
git pull origin PR2

git checkout PR1
git pull origin PR1

The project status becomes:

• sync PR1 and PR2, then sync PR1 and origin/PR1, PR2 and origin/PR2

git checkout PR2
git merge PR1
git push origin PR2

The project history now becomes:

---

[dorawyy]

Option2: Squash and commit

The 1( 1 in this case) commit from this branch will be added to the base branch

Current project status:

Prep again

git checkout PR1
touch test20_option2
vim test20_option2

git add test20_option2
git commit -m "testcase20(option2): startpoint (create file test20_option2 on PR1 branch)"
git push origin PR1

# then sync PR2 with PR1
git checkout PR2
git merge PR1
git push origin PR2

# now the two branches are synced

Prep edit on test20_option2:

After prep, the project status is:

Step1: Alice made two commits on PR2 branch

• Here is commit1:

git checkout PR2
vim test20_option2
# make changes
git add test20_option2
git commit -m "PR2: commit1, edit file test20_option2, line 16" 

• Here is commit 2:

git checkout PR2
vim test20_option2
# make different changes
git add test20_option2
git commit -m "PR2: commit2, edit file test20_option2, line 17" 

Here is Alice's edit of commit1 and commit2:

Here is the project status after commit2 is also done:

• Push all changes back to remote repo

git checkout PR2
git push origin PR2

Step2:

Bob did nothing

Step3: Alice made a pull request

• First, there is no conflict, the pull request shows there are two commits

• Second, Alice makes the pull request, here is what she filled in:

• Till now, Alice's work is done. Now Bob's turn.

Step4: Bob chose to squash commits and merge

• Bob choose to squash commits and merge

• The default window that Bob will see:

• Here are the info that Bob input:

• After squashing commits done, here is the window that Bob sees:

Step5: Check history changes of branch PR1 and PR2

• There is no change on branch PR2

• As for PR1, all commits on PR2 included in the pull request are squashed, and became 1 commit, showing up in PR1 branch's history

• Note: the squashed commit on PR1 is a normal commit, with only 1 parent.

Step6: Pull all changes back to local, merge, push again ( to sync for next testcase)

git checkout PR1
git pull origin PR1

• At this point, PR1 and PR2 diverged actually [Therefore, we need to merge them again ( though their changes actually are actually the same)
  ]

• If we try to merge via making pull request, here is what we can see:
  • we can make pull request PR1 --> PR2 or PR2 --> PR1
  • if PR1 --> PR2 , showing 1 commit
  • if PR2 --> PR1, showing 2 commits
  • See screenshot for details

Hint here: the merge detection happens between the the latest commit on current branch, and the latest common commit of the other branch

• Merge PR1 and PR2 in a regular merge way: (it should be a three way merging)

# for example, merge on PR1
git checkout PR1
git merge PR2

# three-way merging, a merge commit created

Here is the merge message:

The project status becomes:

Then merge PR2 forward (fast-forward)

git checkout PR2
git merge PR1

The project status becomes:

Then, sync to remote-tracking branches:

git checkout PR1
git push origin PR1
git checkout PR2
git push origin PR2

• Check remote commits:

• Now, the project status is:

[dorawyy]

Option3: Rebase and merge

The n commits from this branch will be rebased and added to the base branch

Current project status:

Prep again

git checkout PR1
touch test20_option3
vim test20_option3

git add test20_option3
git commit -m "testcase20(option3): startpoint (create file test20_option3 on PR1 branch)"
git push origin PR1

# then sync PR2 with PR1
git checkout PR2
git merge PR1
git push origin PR2

# now the two branches are synced

Prep edit on test20_option3:

After prep, the project status is:

---

Step1: Alice made two commits on PR2 branch

• Here is commit1:

git checkout PR2
vim test20_option3
# make changes
git add test20_option3
git commit -m "PR2: commit1, edit file test20_option3, line 16" 

Here is Alice's edit of commit1:

• Here is commit 2:

git checkout PR2
vim test20_option3
# make different changes
git add test20_option3
git commit -m "PR2: commit2, edit file test20_option3, line 17" 

Here is Alice's edit of commit2:

• Push all changes back to remote repo

git checkout PR2
git push origin PR2

Now the project status is:

---

Step2:

Bob did nothing

---

Step3: Alice made a pull request

• First, there is no conflict, the pull request shows there are two commits

• Second, Alice makes the pull request, here is what she filled in:

• Till now, Alice's work is done. Now Bob's turn.

---

Step4: Bob chose to rebase and merge

• Bob choose to rebase and merge

• The default window that Bob will see:

• Bob does not need to input anything

• After rebasing then merge is done, here is the window that Bob sees:

---

Step5: Check history changes of branch PR1 and PR2

• Here is PR2

• Here is PR1

• Observations:
  • PR2 , no change
  • PR1 branch: have the 2 commits from PR2. because PR2 get rebased, then fast-forward merge back to PR1
  • the SHA of the 2 commits on PR1 is different from that of PR2 branch.

---

Step6: Pull all changes back to local, merge, push again ( to sync for next testcase)

• fetch updates on PR1 and PR2 from remote

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

• Now the two branches diverged, see the tree below:

If we try to make a pull request now, both PR2 --> PR1 and PR1 --> PR2 works:

Pull request PR2 --> PR1 :

Pull request PR1 --> PR2 :

---

Step7: If making pull request PR1 --> PR2 to resolve the conflict:

Here is the pull request:

Two commits included, however,

• there is conflict if rebasing (as the screenshot above shows); thus, rebase and merge is disabled
• create a merge commit is still abled
• squash and commit is also abled --> but this one cannot resolve conflict, after which still diverging

-- If merging directly:

-- If squashing commits and merge:

Here, I choose to squash commits and merge (should have new commits on PR2):

If checking branch commits history now,

• PR2:

• PR1:

---

Step8: git pull to local and observe

Now the tree diverge more, thus still needs merging

---

Step9: merge PR1 and PR2

git checkout PR2
git pull origin PR2
git merge PR1

(three way merging)

Now the project history is like:

git checkout PR1
git pull origin PR1
git merge PR2

( a fast-forward merging)
The project history becomes:

# sync with remote repo
git checkout PR1
git push origin PR1

git checkout PR2
git push origin PR2

The project history becomes, all synced: