Best workflow when forking and renaming a GitHub project

Nic Strong picture Nic Strong · Apr 14, 2011 · Viewed 11.1k times · Source

I am trying to figure out the best workflow for working with a fork of an existing opensource project in Github. I want to take an existing project and make significant changes to it, in this case to port it to android and add specific android only functionality. I would like to satisfy the following:

  1. Be able to pull changes from their public repo to the new android port as the original code is updated.
  2. Be able to sumbit changes (via pull requests) to the orginal project when I fix bugs that aren't just applicable to the android port.
  3. Have a seperate renamed version of the project to make it clear that it is a Android port. I looked at renaming a fork and Github gave me huge warnings about doing this.

My initial thoughts are I would fork the original project then fork and rename my fork to give me the following repos:

original-author/projectA
nicstrong/projectA
nicstrong/projectA-android

This would allow me to work on my local repo local/projectA-android push changes to nicstrong/projectA-android. Then to update from the orginal project I could rebase nicstrong/projectA to the latest from original-author/projectA then fetch/merge from nicstrong/projectA to local/projectA-android.

My questions are:

  1. I am quite new to the whole Git thing. Does this seem like a good approach? Or is there a better workflow for handling this scenerio?
  2. How would I handle pushing from projectA-android back to nicstrong/projectA so I can setup pull request for the original project?

Answer

VonC picture VonC · Apr 14, 2011

1/ Yes, that seems the safest approach, as any modification you end up back-porting in nicstrong/projectA will be in a project with the same structure as original-author/projectA.
That means pull requests will be easier to organize, since you will be in a project mirroring the original author's project.

2/ If you have massive refactoring going on in nicstrong/projectA-android, I would make a backport branch, carefully merge or cherry-pick what you need from the numerous changes to the backport branch, and then push that branch to nicstrong/projectA.
(which means you have added nicstrong/projectA as a remote of nicstrong/projectA-android)