How to use Github with the shared repository model and Aptana?

We h开发者_C百科ave a small development team, all working in the same room. We're setting up Github to manage a number of medium/ large projects. We are all new to Github but want to use it as our projects are based on open source software hosted on Github.

With our situation the "shared repository model" looks ideal - where each developer has full Git privileges.

We'd like to use the following process:

1. Each developer works with their own version of the project using Aptana as an IDE.
2. Each developer regularly gets updates from, and commits to the repo
3. We regularly update a demo version of the project sourced from the repo to show to project stakeholders.

All of this is pretty standard stuff but we're struggling to find some clear documentation or a "how to" for setting this up. The Github documentation seems to be aimed at open source collaboration.

It may be we don't fully understand the Git terminology, we come from a background of Subversion and one dev has used Mercurial.

Can someone please suggest some clear documentation or a how-to for a setup of this type.

Thanks in advance.

First, create several branches on your repo like:

• master - that's the one representing your current release
• develop - that's the one holding the latest completed dev tasks (i.e. user stories)

When a developer starts working on a new user story, he creates a new branch from develop using:

git fetch
git checkout develop
(git pull origin develop) <-- only if you are not yet on head of develop
git checkout -b new-feature-branch

Now the dev only works on this feature branch. After completing his work, he creates a pull request from his feature branch towards develop. Other devs will take a look at it on GitHub, review his changes. If rework is required, the dev continues pushing changes to his feature branch, because the pull request will be updated along with it. If everything is fine, the pull request is merged into develop.

From time-to-time, you merge your changes from develop to master, again using pull requests. If you have no good test coverage and continuous integration, you might need an additional branch between master and develop to first stabilise your code.

This model assumes that your feature branches are short lived, e.g. 1-2 days.