• Page
• Discussion
• View source
• History
• Edit

From Eclipsepedia

Please enter in any Git Workflows you may have as a committer, non-committer or even as an OrionHub, GitHub or Localhost user.

If there are any workflows specifically not capable of being done in Orion, those are of special interest.

Contents 1 Workflows 1.1 Github Fork as Private Branch 1.2 Serial Branches with Review-limited Upstream Commits 1.3 Resolve Merge Conflicts

Workflows

Github Fork as Private Branch

I guess this is typical github use pattern.

1. Fork a github project
2. Clone into Orion
3. Commit to new branch on Orion
4. Push
5. Use Pull request on GitHub
6. Abandon your branch or entire fork.

Note that at step 5, your commit history is lost and irrelevant.

In theory you run into a problem if you Pull request is successful but then you continue to commit to the branch you used in the Pull request.

Serial Branches with Review-limited Upstream Commits

Here I am trying to move forward in small reviewable chunks that depend upon each other.

1. Clone the git repo
2. Create Feature1 branch
3. Commit 1, 2, 3 (test interleaved).
4. git fetch and rebase to master if it has advanced. Retest
5. Submit patch for review (we use git cl, https://codereview.appspot.com)
6. Create Feature2 branch from Feature 1.
7. Commit 4,5.
8. checkout FB1, the review is back from commits 1,2,3.
9. git fetch rebase master if it has advanced, retest.
10. git reset master # dump the changes from 1,2,3 onto your workspace
11. git checkout master # now the changes are relative to master, re-test
12. git commit -a -m "publically useful commit message with bug# and review URL"
13. push to origin/master.
14. checkout -b FB2.1 # relative to master
15. cherrypick c4, c5 off branch FB2.
16. retest and delete FB1 & FB2

Now you can go back to step 6 or 7.

Here is a picture:

 branch from master to FB1
 commit 1,2,3 on FB1
 branch from FB1 to FB1.2
 commit 4, 5 on FB1.2
 squash commits 1,2,3 from FB1 into commit 6 on master

master   C0 <--- C6
           \
FB1         C1 <-- C2 <-- C3 
                            \
FB2                          C4 <-- C5

Goal: continue on FB2 with a history matching master

master   C0 <--- C6
                   \
FB2                 C4' <-- C5'

Resolve Merge Conflicts

The cause of conflicts has variations but here is a major one.

1. You modify a file and save it.
2. Someone else modified the same file and pushed it into remote.
3. In git status page, you fetch and merge.
4. You file is marked as conflicting.
5. Open the side by side compare editor and resolve the conflicts.
6. Stage the file and commit it.
7. Push your file into remote.

For other variations and details, refer to test cases of resolving conflicts.