Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Orion/Git Workflows"
(→Workflows) |
(→Workflows) |
||
| Line 5: | Line 5: | ||
== Workflows == | == 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. | ||
| + | |||
| + | # Clone the git repo | ||
| + | # Create Feature1 branch | ||
| + | # Commit 1, 2, 3 (test interleaved). | ||
| + | # git fetch and rebase to master if it has advanced. Retest | ||
| + | # Submit patch for review (we use git cl, https://codereview.appspot.com) | ||
| + | # Create Feature2 branch from Feature 1. | ||
| + | # Commit 4,5. | ||
| + | # checkout FB1, the review is back from commits 1,2,3. | ||
| + | # git fetch rebase master if it has advanced, retest. | ||
| + | # git reset master # dump the changes from 1,2,3 onto your workspace | ||
| + | # git commit -a -m "publically useful commit message with bug# and review URL" | ||
| + | # push to origin/master. | ||
| + | # checkout -b FB2.1 # relative to master | ||
| + | # cherrypick c4, c5 off branch FB2. | ||
| + | # 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' | ||
[[Category:Orion|Git Workflows]] | [[Category:Orion|Git Workflows]] | ||
Revision as of 18:08, 5 March 2012
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.
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.
- Clone the git repo
- Create Feature1 branch
- Commit 1, 2, 3 (test interleaved).
- git fetch and rebase to master if it has advanced. Retest
- Submit patch for review (we use git cl, https://codereview.appspot.com)
- Create Feature2 branch from Feature 1.
- Commit 4,5.
- checkout FB1, the review is back from commits 1,2,3.
- git fetch rebase master if it has advanced, retest.
- git reset master # dump the changes from 1,2,3 onto your workspace
- git commit -a -m "publically useful commit message with bug# and review URL"
- push to origin/master.
- checkout -b FB2.1 # relative to master
- cherrypick c4, c5 off branch FB2.
- 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'