-
Notifications
You must be signed in to change notification settings - Fork 34
Home
This document aims to help developers with working on the beebem-windows codebase.
The main beebem-windows repository treats the master branch as stable, in that it's the branch which has the most tested code on it, and the branch from which releases are made. Formal releases of BeebEm are tagged, in the form x.y. Untagged code may well accumulate on master, which will go to form the next release.
Other branches in the repository are:
-
no-master-128-- This branch contains release 1.05. -
robert-schmidt-- This branch contains a build of BeebEm 0.04 by Robert Schmidt.
When you fork a repository it is up to you to keep your clone up to date with any changes made to it. Typically, this will involve the master branch. Please do NOT make commits directly to your copy of the master branch. This branch is reserved for aggregating changes from other people; a branch where you pull in changes from upstream before submitting a pull-request. That way, your changes are guaranteed to be current. If they're not -- or the review process means changes are necessary -- then they should be reflected locally on your topic-branch before pushing those changes out. For example, see:
https://help.github.com/articles/syncing-a-fork/
For the purposes of this document, we've assumed a remote of upstream points to the main stardot/beebem-windows repository.
See the section on "Keeping your fork in sync" first of all.
External contributions are always welcomed and encouraged. If you're thinking of writing a new feature, it is worthwhile opening an issue against beebem-windows to discuss whether it's a good idea, and to check no one else is working on that feature. Additionally, you can also post to the main BeebEm thread on the StarDot forums.
Those wishing to submit code/bug-fixes should:
- Fork the beebem-windows repository
- If not already done so, clone that repository locally
- Add the stardot beebem-windows as an upstream
remote:
git remote add upstream [email protected]:stardot/beebem-windows.git git fetch upstream - Create a topic-branch to house your work. One branch per logical change is preferred.
- Rebase it against
upstream/master - Push the latest changes to your fork
- Open a pull-request
Once a pull-request is opened, someone from the BeebEm development team will take a look at it.
This article further explains the rebase workflow.
The history of master should be as linear as possible, therefore when merging changes to it the branch(es) in question should be rebased against master first of all. This will stop a merge commit from happening.
If using GitHub this process is easy, since the Merge pull request button has an option to Rebase and Merge. This is what should be used. See also the documentation on GitHub
This can be done manually:
git checkout topic/branch
git rebase origin/master
git checkout master
git merge topic/branch
git push