Youry's Blog

Youry's Blog

github advises

leave a comment »

Permission to publish:
 Please feel free to put my comments in your blog!  I ended up copying the message to my own website, at the suggestion of one of the other folks who replied.  http://tinylittlelife.org/?p=288  So, whatever’s easiest for you — copying or linking — works for me.  Glad I could help!
 -Ian
++++++++++++++++++++++++++++++++++++++++++++++++++++++
David, I'm CCing the list with my response to the question you had
when we spoke.  Hopefully it will help a few other folks, it's
actually a pretty common use case.

Say that you are following someone else's project on github, and you
want to submit a patch to their code.  Unfortunately you don't have
access to their repository.  Github recommends that you create a fork
of their project -- which is correct -- but from there, their
instructions are less helpful.

So, assuming that you've created a personal fork of their project,
here is how you contribute your code:

First, checkout THEIR project and get into that directory
 $ git checkout git://github.com/their/project.git
 $ cd project

Now, add your fork as a remote repository, and give it the alias "bananas"
 $ git remote add bananas git://github.com/your/fork.git

Make any changes you need to make, "git add" and "git commit" as appropriate.
 $ git add myfile.txt
 $ git commit -m "i made changes"

Get the latest version of their code.  (Note that you are putting your
commits on top of their project's master -- not yours.  This is
correct, and allowed; you just won't be able to push these changes to
their repo.)
 $ git pull --rebase

Since you can't push to their repo, push the changes to YOUR repo
(which you called "bananas"), in a new branch called "onions"
 $ git push bananas master:onions

The above command is taking their master branch with your commits on
top of it and making a new branch in your personal fork.  You could
omit the "master:onions" bit, but then it would by default go into
your "master" branch.  In a perfect world, that would be fine... but
in the real world, they might reject your changes (in which case, you
have a lot of cleanup to do and even more so if you continued to
commit and push).  So make a new branch for every set of changes you
want to submit.  I tend to prefix my branches with the date (e.g.
"2012-06-29_onions").

Now that github has your changes, put their branch back the way that
it was -- keep everything all tidy.
 $ git reset --hard origin/master

If you go to github now, you should see a new branch called "onions"
-- send a pull request based on this branch.  Github just rolled out a
new feature where it notices new branches and gives you a convenient
link to send the pull request (from the main page of your fork, I
believe).

From here, 1 of 3 things will happen:

1. They accept your changes.  You run "git pull --rebase" and get the
now-official code that you contributed.

2. They reject your changes.  You start over from scratch at the
add/commit step (since you reset your branch), and repeat the process.

3. They reject your changes, but you want to keep building on those
changes.  You do "git merge bananas/onions" to pull in the branch that
you were working on, then add/commit to it as appropriate.  Then you
can "git push bananas master:onions" again and update your pull
request on github.

When you are all done with your branch, you can delete it by pushing a
null branch to it:
 $ git push bananas :onions

Good luck!

-Ian
Advertisements

Written by youryblog

July 4, 2012 at 11:18 PM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: