42

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?
Nic Strong
  • 6,363
  • 3
  • 32
  • 49

2 Answers2

19

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)

Chris
  • 5,099
  • 3
  • 30
  • 45
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • 2
    To create the multiple forks needed, I used the technique described in this post: http://adrianshort.org/2011/11/08/create-multiple-forks-of-a-github-repo/ – dbasch Aug 19 '13 at 08:23
  • 1
    @dbasch true, but it won't be a true fork, in that there won't be any pull request from a second "fork" back to the original repo. – VonC Aug 19 '13 at 08:25
  • I will use the projectA repository for pull requests to the original repo. Changes in projectA-android/backport will be manually merged to projectA. Is this a good strategy? – dbasch Aug 19 '13 at 08:55
  • 4
    Please notify my girlfriend that I did something correctly, for once. Your answer given in this post was also very helpful for understanding this topic: http://stackoverflow.com/a/15734936/168205 – dbasch Aug 19 '13 at 08:59
  • Note: Add projectA as a remote for the local repo projectA-android. Name the remote upstream. – dbasch Aug 19 '13 at 09:10
  • @dbasch on the same topic, http://stackoverflow.com/a/3903835/6309 is also helpful. – VonC Aug 19 '13 at 10:23
  • .@VonC That helped to explain the fetch/merge/rebase options for syncing projectA with projectA-android. – dbasch Aug 20 '13 at 09:20
4

The name of a git repository is heavily dependent on the name of the remote. Go ahead and clone it, then just add a new remote (by a different name) and begin pushing there. At that point, of course, you can go ahead and change the name of the project directory without issue.

Jordan Scales
  • 2,637
  • 3
  • 26
  • 36