Skip to end of metadata
Go to start of metadata

 http://workingontologist.com/FIBO/FIBO-Github-Demo/FIBO-Github-Demo.html


Cheat sheet

Setup: In parallel

  1. Blue team makes change: Resolution O
  2. Green team makes change: Resolution P

GOAL: make the history look like O was done first, then P.

  1. Select Resolution P branch (now the current branch)
  2. Right click on Resolution O branch, select rebase option.
    This  means take all the changes made on P and apply them to O.



  3. Look at the warning popup and if it looks right, press OK



  4. The history is now changed, it looks like O was done then P

Use Case: Go back and make a change on an old branch

Generic instructions to make a change on OldBranch (e.g. FND-129) and make it look like it happened on LatestBranch (e.g. FND-140)

  1. Make OldBranch the current branch 
  2. Make and commit the change on OldBranch. OldBranch and NewBranch will now be on separate commit paths.
    Next. we want to make it look like the new commit just made on OldBranch is on the SAME commit path as and happende after NewBranch
  3. Right-click on the NewBranch
    Select the rebase option from the dropdown
  4. Examine the pop-up to make sure it does what you want
  5. Click OK. It looks like the figure below. Note that there are a lot of subsequent changes that need to be pushed to origin on 129 which was last touched 10 days prior.

Detailed example

Here is an example of this being done in real life, doing real work.  I had completed work on a branch called FND-129 corresponding to a JIRA of the same name. I made quite a few commits after that and I need to go back and make some changes on the FND-129 branch. This is how I proceeded:

Starting situation: 


  1. Make FND-129 the current branch 


  2. Make and commit the change on that branch in the usual way
    (analogous to "Resolution P" above). It should look like this, now 129 and 140 are on separate commit paths.



  3. Now we want to make it look like the last commit happened after the commit from FND-140 on the SAME commit path.
    Right-click on the latest branch, in this case FND-140
    (analogous to "Resolution O" above)
  4. Select the rebase option from the dropdown

  5. Examine the pop-up to make sure it does what you want

    This is exactly what we want to do. 

  6. Click OK. It looks like the figure below. Note that there are a lot of subsequent changes that need to be pushed to origin on 129 which was last touched 10 days prior.

3 Comments

  1. Another important use case (which I got wrong recently with DER-24) is if you're working on your own branch and you want to ensure you're working with the latest from EDMC/master. In this case you should do a rebase instead of a pull. The problem with doing a pull (which is what I did) is that it shows up as another merge commit point in the history which is a bit messy and makes it harder for people to review the subsequent PR.

    This is quite good: https://www.atlassian.com/git/tutorials/merging-vs-rebasing and this https://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ 


    1. Very interesting. I only ever to a pull from EDMC/master.  I don't fully understand how this results in the downside you describe.

  2. Look at the changes for DER-24 (PR #335) and you'll see a couple of merges from master. If I had done a rebase you would not see those.