Best workflow when forking and renaming a GitHub project [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

开发者_如何学Go

Closed 7 years ago.

Improve this question

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?

---

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)

---

2022: Note that you can create a fork directly with a different name.

---

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.