-
Notifications
You must be signed in to change notification settings - Fork 749
Github & Git
This page describes how we use Git & Github. It is aimed at individuals and organisations who may wish to get/use the source code, or contribute back to the source code through the collaboration model.
We use Github & Git as we want:
- To simplify the way individuals and organisations can get access to the source code of our software.
- Allow individuals and organisations to independently make changes and extend the software for their own needs
- Allow individuals and organisations to easily contribute back any work they do through the Fork & Pull model.
Developers should follow the instructions below to make the above possible.
- Pro Git book - http://git-scm.com/book/
- Git workflows book - http://documentup.com/skwp/git-workflows-book
- Git quick reference - http://gitref.org
- ThinkUp develop from source
Note: The ThinkUp documentation on developing from source is very good. I will most likely change our documentation to that style/format and come up with a graphic to illustrate what we do which would be very much the same as the one they have created.
see Git pro book online for instructions for your operating system: http://git-scm.com/book/en/Getting-Started-Installing-Git
see Git pro book for what to do for first time setup: http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup
Of note is:
$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
and git config --list to check your git configuration.
When on windows, make sure to check that the following is set: core.autocrlf=true
We do this when using git on windows as all the files in the respository should have LF line endings. With core.autocrlf=true, all LF line endings are converted to CRLF line endings on checkout to a Windows machine. All files are converted back to LF line endings on commit from a Windows PC.
If you dont have a github account already then you need to sign up and create one on on github.com (free accounts are fine).
Once you have a github account, the next step is to fork https://github.com/keithwoodlock/mifosx.
see https://help.github.com/articles/fork-a-repo for help on forking in github.
Create a directory in which you want the cloned project to exist within: e.g. in directory c:/dev/githubrepos/
git clone [fork repository url]
For example:
[email protected]:USERNAME/mifosx.git
see https://help.github.com/articles/fork-a-repo for help on forking in github
see https://help.github.com/articles/which-remote-url-should-i-use
After the clone operation has completed (should be pretty quick), you should have a directory structure like the following:
mifosx:
- mifosng-db
- mifosng-provider
When a repository is cloned, it has a default remote called origin that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you should add another remote named upstream:
git remote add upstream [email protected]:keithwoodlock/mifosx.git
Its probably easiest if you create a new 'topic' branch on your forked repository for each unique piece of work rather than commit changes directly into master. Why?
It means you can work on something very specific, get it up to date and send a 'pull request', To move on to a seperate piece of work, you simply create a different branch. It might also make it easier to keep up to date with the keithwoodlock/mifosx repository as explained in next section.
There will be development changes to the keithwoodlock/mifosx almost every day for the foreseeable future so its important to keep your fork of the software up to date with the latest changes.
To pull in upstream changes from repository you forked:
git checkout master ... to make sure you are on the master branch
git fetch upstream ...fetches changes from upstream respository but does not merge/rebase them
git merge upstream/master ... merge in the new changes from upstream/master repository into your repository and branch (should be master)
git checkout my-topic-branch ... switch to the topic branch you are using for piece of development work
git rebase master ... rebase your topic branch which means, take in all latest changes and replay your work in topic branch on top of this - this produces cleaner versions/history
Note: the use of rebase for pulling in changes on top of your possible local dev changes as opposed to merge.
Read more about this at http://help.github.com/fork-a-repo/
git push origin [branchname] e.g. git push origin master
We would expect people to use the Fork & Pull model for collaborating back. Simply this means that we expect you to use Githubs tools here and to send pull-requests to us when you have a piece of work you want to contribute back.
Read more here: https://help.github.com/articles/using-pull-requests
Optional: If possible, it would nice if you could have your work in one commit rather than several broken up commits. If you followed advice on using a 'topic-branch' for you work and you have used rebase to get your changes up to date with the latest, and its only you doing work, you should be able to squash your changes over several commits into one commit
git rebase -i HEAD~2 ... squash last two commits i did on this branch into one.