How to best work with a "forked" a git repo, and push some new features back to origin

Question

Hi all,

I'm having a blog-project on GibHub, where a friend of mine, wants to base his code on. He will make some changes to some files that he do not wish to commit back to me (maybe stylesheets and images), but he will maybe implement a new feature that he would like to push back to my project.

He should also be able to get new code from me, where he would like to get all new stuff.

I've looked around, and it seams that Rebase is the way to go for him, to get updates from me, but how can he most easily push a feature back to me? (He is just learning Git, as well as me)

Answer 1

He should create a branch which will mirror your "upstream" branch, commit/merge/cherry-pick to it the commits he wants to push upstream, and sometimes do a git-push to a branch in your repo. Then you should review the commits in that branch and merge them to your main branch.

Answer 2

git clone git://yourrepo.com/project.git

Create a tracked remote branch. This means that pulls and push operations are automatically done with the main branch. The track branch might be origin/dev or origin/master. Whichever.

git checkout --track -b mylocalbranch origin/trackedbranch

After that a normal git work flow is done with local commits and such. Occasionally he should,

git pull --rebase

This will perform a rebase operation which rolls back his changes, pulls in the changes made to the remote branch, then replays his local changes on top of that (resolve any conflicts; perform any merges).

When he's done and wants to make those changes live, he should bring things current:

git pull --rebase # get most recent changes

Then, for a bare repository:

git push # push his changes to the main repo

If it's a non-bare repository (like your repository in your home folder or some such), then it's preferred that he notify you that he's ready and then you do the

git pull /path/to/his/repo

It's generally advised not to push to non-bare repositories. The reason being you could have uncommitted changes in your local and when he pushes to it, chaos can ensue details. Kernel trap thread discussing this pit fall

Answer 3

It seems like you are describing a workflow where a feature is developed concurrently with the main branch. The answers above are good, but it should be noted that a "rebase" is not always necessary. Especially for a git beginner, since a rebase amounts to a history modification, is an intermediate concept, and is not always what you want if you want to keep information about where and when a branch is made in your commit history.

When your friend wants to pull in changes from your main branch, he can always use plain, vanilla merge instead of rebase:

git fetch origin
git merge origin/master  # or any branch he wants to merge other than "master"

When you want to pull your friend's changes, you can do a similar operation:

git fetch friend
git merge friend/feature  # choose any of your friend's branches to merge with your current

The above workflow works if you have a URL (local or otherwise) to his repository. Pushing to a non-bare repository (yours) is dangerous, as noted above. If you need your friend to be able to push, use a public, bare repository.

If you want to only select specific revisions from your friend's branch to pull, use the cherry-pick command:

git fetch friend
git log friend/feature  # or `git log friend`
# find the commit you want to cherry pick, then
git cherry-pick <commit>