-
Notifications
You must be signed in to change notification settings - Fork 130
GitHub Access
In an attempt to ease the process of contributing code and patches to the MisterHouse code base, a git repo has been setup in November 2012.
The repository lives here and can be cloned to your own Github account for code development.
Advantages of the github account compared to the SVN repository include:
- Easy diffs between various versions and branches
- Invites people to actually contribute code back to the main code tree when they develop some local changes (through pull requests)
- Inherent availability of tgz files when creating a tag for people that just want to download and use such a version
To get the source code from the git repository, please follow these instructions.
A quick-start guide into using git.
- Create a github account an prepare your environment for committing. This means that you will define your username and email address that will be used when you commit changes. See https://help.github.com/articles/set-up-git for details. The most handy way to interface to git is using SSH keys.
- Fork the misterhouse repo I created (single button click in the right upper corner here: https://github.com/hollie/misterhouse)
- Clone your fork to your local machine with: git clone git://github.com/tmaclean/misterhouse.git This automatically sets the origin to your repository
- Create a branch where you will develop your change (cd misterhouse; git checkout -b feature_x)
- Develop, test
- Stage the files you want to commit (this means telling git what files you will commit in the next step): git stage <files></files>
- Commit. This will commit the changes to your local repo: git commit -m "Descriptive message here"
- Push your changes to your github repository: git push origin feature_x
- Create the pull request by navigating to your github web page, clicking on the commit, and then click the 'pull request' button. More details, see here: https://help.github.com/articles/using-pull-requests
- $> git checkout -b feature_x
- add/modify code
- $> git stage <files></files>
- $> git commit -m <descriptive></descriptive>
- $> git push origin feature_x
- create the pull request
Finally, a general quick overview of basic git usage can be found here: http://rogerdudler.github.com/git-guide/
When developing an open source project, it is important to not have a single person being responsible for maintaining the main code branch. On the git account, this is done first of all inherently by the working principle of git. If I ever run under a bus, anybody else willg to do so can fork the main repo and change the link at the top of this page to his/her user account, thereby taking over the repository. Moreover, to avoid that changes don't make it to the main branch because of me being on an extended vacation to the Bahamas, other volunteers/developers/enthousiasts are permitted collaborator access to the repository on my user account. Currently, the list of people who are able to make changes to the repo are:
- hollie (Lieven Hollevoet)
- marcmerlin (Marc Merlin)
a.k.a. contributing code.
So, git is a different beast compared to SVN. The reasoning behind going for git were already listed. This section shows you how to contribute code.
- Create your account on github.comand log in.
- Through the web interface, fork the MisterHouse repository from here
- Now you have your own fork that you can use to work on. Clone it to your working machine: git clone [email protected]:/misterhouse.git
- You now have a copy of the master branch of your fork on your computer. Prepare it to start implementing changes by creating a branch to work in. It is considered bad practice in git to directly work on the master branch because this complicates the exchange of the code you added or changed. Suppose you make a change and somebody else want to continue working on it. If the change is made in a branch that person can pull your changes into his/her repo and contribute to your work. If you made various changes to your master branch then it is hard to determine what changes need to be pulled in to help you further. Making the branch to work on is easy 'git branch feature_xyz' followed by 'git checkout feature xyz'.
- Work on the code, test
- Stage: git stage <files></files>
- Commit: git commit. In the editor that appears, enter a first line with a short description of the change, then an empty line and then a longer description. This will be useful when creating the pull request later.
- Publish the branch with the change: git push origin feature_xyz
- Then in the web interface navigate to the commit, click the 'create pull request' button and the next screen will be auto-filled in with the info you put in the commit message. Title will be the first line of the commit, body will be the content you added to the commit message after the empty line.