This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: Git Forks And Upstreams: How-to and a cool tip
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
There are tons and then some useful guides on how to keep your forks updated against the upstream repositories (and if you’re wondering why you would want to use forks in an enterprise setting, check out a few reasons here). In this blog I will introduce you to few aspects of how forking interacts with upstream: the basics, the gotcha’s, and an cool tip. To top it off I will then make you very jealous, or very eager, the choice is yours. Interested? Read on. The base workflow to keep up-to-date and contribute Let me start by detailing a common setup and the most basic workflow to interact with upstream repositories. In a standard setup you generally have an origin and an upstream remote – the latter being the gatekeeper of the project or the source of truth to which you wish to contribute to. First, verify that you have already setup a remote for the upstream repository – and hopefully an origin too: 1234git remote -v origin git@bitbucket.org:my-user/some-project.git (fetch) origin git@bitbucket.org:my-user/some-project.git (push) If you don’t have an upstream you can add it simply with the remote command: 1git remote add upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git Verify that the remote is added correctly: 123456git remote -v origin git@bitbucket.org:my-user/some-project.git (fetch) origin git@bitbucket.org:my-user/some-project.git (push) upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (fetch) upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (push) Now you can collect the latest changes of the upstream repository with fetch (repeat this every time you want to get updates): 123git fetch upstream (If the project has tags that have not merged to master you should also do: git fetch upstream --tags) Generally you want to keep your local master branch as a close mirror of the upstream master and execute any work in feature branches (that might become pull requests later). At this point it does not matter if you use merge or rebase, the result will typically be the same. Let’s use merge: 12git checkout master git merge upstream/master When you want to share some work with the upstream maintainers you branch off master, create a feature branch and when you’re satisfied you push it to your remote repository. You can also use rebase instead then merge to make sure the upstream has a clean set of commits (ideally one) to evaluate: 1234567git checkout -b feature-x #some work and some commits happen #some time passes git fetch upstream git rebase upstream/master If you need to squash a few commits into one you can use the awesome rebase interactive at this point. After the above, publish your work in your remote fork with a simple push: 1git push origin feature-x A slight problem rises if you have to update your remote branch feature-x after you published it, because of some feedback from the upstream maintainers. You have a few options: Create a new branch altogether with the updates from you and the upstream. merge the updates from upstream in your local branch which will record a merge commit. This will clutter the upstream repository. Rebase your local branch on top [...]
Previous Topic
