Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is a project on Github that I mostly like and want to use. There are a few things I want to do differently/remove that doesn't make sense for what I want/need. Also I want to add a few things as well.

As I understand it, I should fork the project and I can make whatever changes I want and push back to my fork. From there, I also want to occasionally pull into my fork the changes from the original project so I get the latest bug fixes/features.

Am I off-base of how I think it should work? How would bring in the changes from the original project?

share|improve this question
You may find this helpful:… – Michael Durrant Jun 21 '12 at 19:30
up vote 13 down vote accepted

Make the fork, then make a branch immediately.

Now you have an "untouched" master that can be updated itself going forward to get the latest changes with git pulls.

Keep you branch local without pushing to remote and you can do rebases which will do the following for you:

  • save away your changes
  • apply the latest changes from master to your branch (the ones that came from the update from the remote)
  • reapply your changes again, on top of the code that was updated from master (or other original branch).

When you are finally done with it, merge it back into master (or whatever branch the initial fork was from) locally and then submit the pull request for the actual owner to pull it in.

That's one workflow (or "forkflow") anyway, as I understand it. Others are welcome to comment or correct or add more detail.

share|improve this answer
This does seem a bit off-topic. It addresses the 'how' without much explanation of what you're doing, and avoids getting into the etiquette question. You could improve this by giving a high-level overview of what you're accomplishing, and explaining why it's good manners to do it this way. – Justin Morgan Jun 21 '12 at 5:27

You basically have it: once you create a fork, it's your own little sandbox.

I think the main thing that you need to do is immediately create a branch after you fork, in order to keep the original line of development separate from your own. Whether you develop in this branch or in master is largely a matter of personal taste. The one thing that would keep me from developing in master is that it's too easy to do a "git pull" and get the wrong thing.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.