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

[dorawyy]

PR2 branch was derived from PR1

Scenario abstract

--> Different branches inside one repo, both Alice and Bob commit (causing conflicts)

• 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, fileX, line Y, locally
• Alice git push origin PR2
• Bob made commits on PR1 branch, fileX, line Y, 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

• createtest23 as test file on PR1
• create PR2 branch from PR1 branch

git checkout PR1
touch test23
vim test23
git add test23
git commit -m "testcase23: startpoint (create file test23 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 test23 :

Startpoint - project tree:

---

Step1: Alice committed on PR2 , test23, line14, pushed back to remote

git checkout PR2
vim test23
# edit test23, line 14

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

git push origin PR2

The edit on the file test23 is:

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

---

Step2: Bob committed on PR1, test23, line14,(same line as Alice), pushed back to remote

git checkout PR1

# edit test23, line14

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

git push origin PR1

The edit on the file test23 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: #59 ):

Note: merge conflict here

---

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

Note: merge conflict here

---

Step5: Bob needs to resolve the conflict first

Bob can use web editor or command line to resolve the merge conflict;

In this test case, we simply use Web editor, might use command line in later test cases

Way1: web editor to resolve conflict

[open web editor]

[resolve conflict]

[merge back]

Now, come back to the pull request page

Note that option3: rebasing is disabled, which is because there is merge conflict before. If rebasing, will meet the same conflict again, which cannot be automatically resolved, Github then disabled that.

Git pull to local, check repo status

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

Commits history of PR2 (head branch)

Details of the merge commit:

---

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 (head repo, no change):

Observations:

• PR1:

  • the commits on PR2 ( head branch) also applied here
  • a pull request merge commit is created

• PR2:

  • no change, now behind PR1

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:

[dorawyy]

PR2 branch was derived from PR1

Option2

Scenario abstract

--> Different branches inside one repo, both Alice and Bob commit (causing conflicts)

• 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, fileX, line Y, locally
• Alice git push origin PR2
• Bob made commits on PR1 branch, fileX, line Y, 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 squash commits then merge?

Results:

• Option2: When squash commits and merge,

Data could be explored:

• Option2: When create a merge commit

---

Detailed steps:

Step0: prep

• createtest23_option2 as test file on PR1
• sync PR2 branch with PR1 branch

git checkout PR1
touch test23_option2
vim test23_option2g
git add test23_option2
git commit -m "testcase23_option2: startpoint (create file test23 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 testcase23_option2 :

Startpoint - project tree:

---

Step1: Alice committed on PR2 , test23_option2, line14, pushed back to remote

git checkout PR2
vim test23_option2
# edit test23_option2, line 14

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

git push origin PR2

The edit on the file testcase23_option2 is:

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

---

Step2: Bob committed on PR1, test23_option2, line14,(same line as Alice), pushed back to remote

git checkout PR1

# edit test23_option2, line14

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

git push origin PR1

The edit on the file testcase23_option2 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: #60 ):

Note: merge conflict here

---

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

Note: merge conflict here

---

Step5: Bob needs to resolve the conflict first

Bob can use web editor or command line to resolve the merge conflict;

In this test case, we choose to use command line:

First, fetch all remote updates to local:

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

The project history becomes:

Way2: command line to resolve conflict

Bob, PR1, test23_option2:

Alice, PR2, test23_option2:

Nothing showed here. Go back to web editor and try resolve the conflict.

Way1: web editor to resolve conflict

[resolve conflict]

[merge back]

Now, come back to the pull request page

Note that option3: rebasing is disabled, which is because there is merge conflict before. If rebasing, will meet the same conflict again, which cannot be automatically resolved, Github then disabled that.

Git pull to local, check repo status

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

Commits history of PR2 (head branch)

Details of the merge commit:

---

Option2: Squash commits and merge

Bob chose to squash commits and merge

Bob filled in info when squash commits and merge

Then the pull request is done

Check PR1 and PR2 commit history

History of PR1 branch: (a squash commit created)
(before squash commits)

(after squash commits)

History of PR2 branch (head repo, no change):
(before squash commits)

(after squash commits)

Observations:

• PR1: (head branch)

  • a squash commit is created, however, it is a normal commit (with 1 parent)

• PR2: (base branch)

  • no change

Details of the squash commit on the base branch is:

Pull PR1 and PR2 to local again ( still diverge)

git checkout PR1
git pull origin PR1

git checkout PR2
git pull origin PR2

The project status becomes:

Merge the two branches PR1 and PR2 locally

git checkout PR2
git merge PR1

git push origin PR2

( three-way merging with no conflict here)

Now the project status becomes:

git checkout PR1
git merge PR2
git push origin PR1

( fast-forward merging)

The project status becomes (all in sync now):