-
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.
There are a few places which contain good instructions on how to do this:
- set-up-git
- Git pro book online http://git-scm.com/book/en/Getting-Started-Installing-Git
- 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 johndoe@example.com
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/openMF/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: git@github.com: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:
The easiest way is to use the https url:
'git init' (to create an empty git repository)
then,
git remote add upstream https://github.com/openMF/mifosx.git
or if you have ssh set up you can use that url instead:
git remote add upstream git@github.com:openMF/mifosx.git
By default when using git you will always have a branch named 'master'. On mifos we use another branch for any current development which we want to put in the next release. It is called 'develop'. You should checkout this branch also.
- master: represents the latest stable release of mifos
- develop: represents the bleeding edge development changes planned for next release of mifos.
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 or our special develop branch. 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 openMF/mifosx repository as explained in next section.
There will be development changes to the openMF/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 'develop' ... to make sure you are on the develop branch
git fetch upstream ...fetches changes from upstream respository but does not merge/rebase them
git merge upstream/develop ... merge in the new changes from upstream/develop repository into your repositories develop branch (You should not have any local changes on your master branch, if you do, use rebase)
git push origin develop ... push up the just merged changes to the develop branch on your fork
git checkout my-topic-branch ... switch to the topic branch you are using for piece of development work
git rebase develop ... 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.
git push origin [branchname] ... do this if you are ready to push up your topic branch to your github account.
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 as follows:
git rebase -i HEAD~2 ... squash last two commits i did on this branch into one.
or you can also reset your latest commits and re-commit as one as follows:
git reset --soft HEAD~2 && git commit ... soft resets last two commits and commits them back (asks for new commit message)
If one of the squashed commits have already been pushed to your remote repository, you need to do a git push origin remotebranchname --force.
For highlighting all usages and click a variable or object to search for other instances in the same project, use CodeNav.
To see IDE-like file browser tree, use Octotree plugin.