[testcase notes] #22: Pull request, different branches inside one repo, both commits, no conflict

[dorawyy]

PR2 branch was derived from PR1

Scenario abstract

--> Different branches inside one repo, both Alice and Bob commit (to different files)

• 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 commits on PR1 branch locally
• Bob git push origin 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?

Results:

• Option1: When create a merge commit,

• Option2: When squash commits and merge,

• Option3: When rebase and merge,

Data could be explored:

• Option1: When create a merge commit

• Option2: When create a merge commit

• Option3: When rebase and merge

---

Detailed steps:

Step0: prep

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

git checkout PR1
touch test22
vim test22
git add test22
git commit -m "testcase22: startpoint (create file test22 on PR1 branch)"
git push origin PR1

git checkout PR2
git merge PR1
git push origin PR2

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

Content of test22:

Startpoint - project tree:

---

Step1: Alice committed on PR2 , pushed back to remote

git checkout PR2
vim test22
# edit test22, line 14

git add test22
git commit -m "PR2: edited the file test 22, line 14"

git push origin PR2

The edit on the file test22 is:

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

---

Step2: Bob committed on PR1 , pushed back to remote

git checkout PR1
touch test22-PR1
# edit test22-PR1

git add test22-PR1
git commit -m "PR1: edited the file test22-PR1"

git push origin PR1

The edit on the file test22-PR1 from PR1 is:

After git push origin PR1, the two branches diverge, here is the status of PR1:

Here is the status of the whole project:

---

Step3: Alice made a pull request to merge PR1(base) and PR2 (head)

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

Here are details of the pull request, created by Alice ( pull request: #37 ):

---

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

---

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.

Bob chose to merge pull request

Bob filled in info when merge pull request

Then the pull request is done

Check PR1 and PR2 commit history

History of PR1 branch:

History of PR2 branch:

Observations:

• PR1:
  • commits on PR2 got applied back to PR1
  • a pull request related merge commit created on PR2
• PR2:
  • no effect on the head branch ( i.e. PR2 here)

Details of the merge commit is:

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

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2
git merge PR1
git push origin PR2

The project status becomes:

---

---

---

Exploring question: Does commit order matters?

• Would commit order influence SHA change or not?

Answer: no, commit order not matter.

Scenario abstract

--> Different branches inside one repo, both Alice and Bob commit (to different files)

• 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)
• Bob made commits on PR1 branch locally
• Bob git push origin PR1
• (the principle here: the base branch commit first)
• Alice made commits on PR2 branch locally
• Alice git push origin PR2
• 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?

Results:

• Option1: When create a merge commit,

• Option2: When squash commits and merge,

• Option3: When rebase and merge,

Data could be explored:

• Option1: When create a merge commit

• Option2: When create a merge commit

• Option3: When rebase and merge

---

Detailed steps:

Step0: prep

• createtest22_order_test as test file on PR1, push to remote
• sync PR1 and PR2

git checkout PR1
touch test22_order_test
vim test22_order_test
git add test22_order_test
git commit -m "testcase22-order-test: startpoint (create file test22_order_test on PR1 branch)"
git push origin PR1

git checkout PR2
git merge PR1
git push origin PR2

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

Content of test22_order_test:

Startpoint - project tree:

---

Step1: Bob committed on PR1 , pushed back to remote

git checkout PR1
touch test22_order_test-PR1
# edit test22_order_test-PR1

git add test22_order_test-PR1
git commit -m "PR1: edited the file test22_order_test-PR1"

git push origin PR1

The edit on the file test22_order_test-PR1 from PR1 is:

After git push origin PR1, the project status is:

---

Step2: Alice committed on PR2 , pushed back to remote

git checkout PR2
vim test22_order_test
# edit test22_order_test, line 16

git add test22_order_test
git commit -m "PR2: edited the file test22_order_test, line 16"

git push origin PR2

The edit on the file test22 is:

After git push origin PR2, the two branches diverge, here is the status of PR2:

Here is the status of the whole project:

---

Step3: Alice made a pull request to merge PR1(base) and PR2 (head)

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

Here are details of the pull request, created by Alice ( pull request: # ):

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

---

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.

Bob chose to merge pull request

Bob filled in info when merge pull request

Then the pull request is done

Check PR1 and PR2 commit history

History of PR1 branch:

History of PR2 branch:

Observations:

• PR1:
  • commits on PR2 got applied back to PR1 ( SHA the same as PR2 )
  • a pull request related merge commit created on PR2
• PR2:
  • no effect on the head branch ( i.e. PR2 here)

Details of the merge commit is:

Make a pull request the other way round

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2
git merge PR1

git push origin PR2

The project status becomes:

[dorawyy]

PR2 branch was derived from PR1

Option2: squash commits then merge

Scenario abstract

--> Different branches inside one repo, both Alice and Bob commit (to different files)

• 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 commits on PR1 branch locally
• Bob git push origin PR1
• Alice made a pull request to Bob: FROM: repo1, PR2 --> TO: repo1, PR1
• What would Bob do and meet?
  • Option2: What if he squash commits then merge?

Results:

• Option2: When squash commits and merge,
  • all commits squashed into 1 single commit, applied to base branch, however, no merge commit;
  • no evidence for merging, the squashed commit is an ordinary commit, with only 1 parent;
  • the head branch is not affected.

Data could be explored:

• Option2: When create a merge commit
  • no merge evidence

---

Detailed steps:

Step0: prep

• createtest22_option2 as test file on PR1
• sync with PR2

git checkout PR1
touch test22_option2
vim test22_option2
git add test22_option2
git commit -m "testcase22_option2: startpoint (create file test22_option2 on PR1 branch)"
git push origin PR1

git checkout PR2
git merge PR1
git push origin PR2

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

Content of test22_option2 :

Startpoint - project tree:

---

Step1: Alice committed on PR2 , pushed back to remote

git checkout PR2
vim test22_option2
# edit test22_option2, line 14

git add test22_option2
git commit -m "PR2: edited the file test22_option2, line 14"

git push origin PR2

The edit on the file test22_option2 is:

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

---

Step2: Bob committed on PR1 , pushed back to remote

git checkout PR1
touch test22_option2-PR1
# edit test22_option2-PR1

git add test22_option2-PR1
git commit -m "PR1: edited the file test22_option2-PR1"

git push origin PR1

The edit on the file test22_option2-PR1 from PR1 is:

After git push origin PR1, the two branches diverge, here is the status of PR1:

Here is the status of the whole project:

---

Step3: Alice made a pull request to merge PR1(base) and PR2 (head)

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

Here are details of the pull request, created by Alice (pull request #43 ):

---

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

---

Option2: Squash commits and merge

step1: Bob chose to squash commits and merge

step2: Bob filled in info when squash commits and merge

Then the pull request is done

step3: Check PR1 and PR2 commit history

History of PR1 branch:

History of PR2 branch:

Observations:

• PR1: (base branch)
  • all commits on the branch PR2 were squashed into 1, and applied to PR1
  • the squashed commit is a ordinary commit with 1 parent
  • no evidence of merging found
• PR2: (head branch)
  • nothing changed on the head branch

Here is the details of the squashed commit on the base branch (PR1 in this case)

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

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

# check tree first 

The two branch still diverge ( according to the project status):

step5: Create a pull request (PR1 --> PR2 vs. PR2 --> PR1 )

( try option3 - rebase and merge) --> to see if enabled or any conflicts?

(1) create a pull request: PR1(head) --> PR2(base) (pull request: #44 )

Details of the content is: (include two commits on PR1)

Rebasing is enabled

(2) create a pull request: PR2(head) --> PR1(base) (pull request: #45 )

Details of the content is: (include two commits on PR1)

Rebasing is enabled

step6: Try the pull request PR1(head) --> PR2(base) (pull request: #44 ), choose to rebasing

( suppose PR2 has new commits)

step7: Check commits of PR1 and PR2

PR1 ( no change) :

• PR2 (only 1 commit get applied, the squashed-commit(d94a5c3) get passed as the textual change there is the same as 12b58d3 on PR2):

The rebase commit (on PR2) details are ( a normal commit):

step8: Pull changes to local to check project status

Still diverge, but pull changes to local to check project status;

# pull PR1
git checkout PR1
git pull origin PR1

After fetching all commits from PR1, the PR1 branch status becomes:

# pull PR2
git checkout PR2
git pull origin PR2

After fetching all commits from PR2, the PR2 branch status becomes:

The project status is:

step9: Manually fixing the divergence

git checkout PR1
git merge PR2
# should be a three-way merge, while no conflict

git push origin PR1

Automatic three-way merging:

Now the project status becomes:

git checkout PR2
git merge PR1
# should be a fast-forward merge

git push origin PR2

Fast-forward merging:

Now the project status becomes, all synced:

[dorawyy]

,PR2 branch was derived from PR1

Option3: rebase and merge

Scenario abstract

--> Different branches inside one repo, both Alice and Bob commit (to different files)

• 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 commits on PR1 branch locally
• Bob git push origin PR1
• Alice made a pull request to Bob: FROM: repo1, PR2 --> TO: repo1, PR1
• What would Bob do and meet?
  • Option3: What if he rebase and merge?

Results:

• Option3: When rebase then merge,
  *

Data could be explored:

• Option3: When rebase then merge
  *

---

Detailed steps:

Step0: prep

• createtest22_option3 as test file on PR1
• sync with PR2

git checkout PR1
touch test22_option3
vim test22_option3
git add test22_option3
git commit -m "testcase22_option3: startpoint (create file test22_option3 on PR1 branch)"
git push origin PR1

git checkout PR2
git merge PR1
git push origin PR2

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

Content of test22_option3 :

Startpoint - project tree:

---

Step1: Alice committed on PR2 , pushed back to remote

git checkout PR2
vim test22_option3
# edit test22_option3, line 14

git add test22_option3
git commit -m "PR2: edited the file test22_option3, line 14"

git push origin PR2

The edit on the file test22_option3 is:

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

---

Step2: Bob committed on PR1 , pushed back to remote

git checkout PR1
touch test22_option3-PR1
# edit test22_option3-PR1

git add test22_option3-PR1
git commit -m "PR1: edited the file test22_option3-PR1"

git push origin PR1

The edit on the file test22_option3-PR1 from PR1 is:

After git push origin PR1, the two branches diverge, here is the status of PR1:

Here is the status of the whole project:

---

Step3: Alice made a pull request to merge PR1(base) and PR2 (head)

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

Here are details of the pull request, created by Alice (pull request ):

---

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

---

Option3: Rebase then merge

step1: Bob chose to rebase then merge

When rebasing is done:

step3: Check PR1 and PR2 commit history

History of PR1 branch:

History of PR2 branch:

Observations:

• PR1: (base branch)

  • a rebase commit is created, with same commit message as the head branch (PR2 in this case)
  • however, the rebase commit is not an ordinary commit, with only 1 parent, and SHA changed compared with that of the head branch (PR2 in this case)

• PR2: (head branch)

  • no change on this commit

Here is the details of the rebase commit on the base branch (PR2 in this case)

step4: Pull PR1 and PR2 to local. check project status

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

# check tree first 

The two branch still diverge ( according to the project status):

step5: Create a pull request (PR1 --> PR2 vs. PR2 --> PR1 ) again

( try option3 - rebase and merge) --> to see if enabled or any conflicts?

(1) create a pull request: PR1(head) --> PR2(base) (pull request: #50 )

Details of the pull request is: (include two commits on PR1):

Rebasing is enabled

(2) create a pull request: PR2(head) --> PR1(base) (pull request: #52 )

Details of the content is: (include one commit on PR2)

Rebasing is enabled

step6: Try the pull request (2) PR2(head) --> PR1(base) (pull request: #52 ), choose to rebasing

( suppose PR1 will have new commits)

The details about the merge commit is ( actually no new commit is created, this is the last rebase commit) :

step7: Try the pull request (1) PR1(head) --> PR2(base) (pull request: #50 ), choose to rebasing

( suppose PR2 will have new commits)

step8: Check commits of PR1 and PR2

• PR1 ( no change) :

• PR2 (only 1 commit get applied, the squashed-commit(d94a5c3) get passed as the textual change there is the same as 12b58d3 on PR2):

The rebase commit (on PR1) details are ( a normal commit):

step8: Pull changes to local to check project status

Still diverge, but pull changes to local to check project status;

# pull PR1
git checkout PR1
git pull origin PR1

After fetching all commits from PR1, the PR1 branch status becomes:

# pull PR2
git checkout PR2
git pull origin PR2

After fetching all commits from PR2, the PR2 branch status becomes:

The project status is (divergence goes further and further):

step9: Manually fixing the divergence

git checkout PR1
git merge PR2
# should be a three-way merge, while no conflict

git push origin PR1

Automatic three-way merging:

Now the project status becomes:

git checkout PR2
git merge PR1
# should be a fast-forward merge

git push origin PR2

Fast-forward merging:

Now the project status becomes, all synced: