-
Notifications
You must be signed in to change notification settings - Fork 0
Contribute
At this moment there are so many ways someone can contribute to the project. Not only the programming is important, we also are looking for people to help with the icons, the art, the music, the documentation, and optimizing the code. If you are interested in helping out in any way please contact us at [email protected] explaining how do you want to help and we'll get in touch with you as soon as possible or just follow this steps:
- Choose or create an issue.
- Start by downloading the git repo
git clone [email protected]:AsustinStudios/Zombie-Labyrinth.git
. - Create a new git branch with your name or the name of the changes you are going to do (eg. 'snoopy' or 'sound effects')
git checkout -b branch-name
. - Put your changes in the corresponding file or folder.
- Add and Commit you changes to the git repo
git add new-or-modified-file
and thengit commit -m "Explain your changes here"
. - Push your branch back to the main repo
git push -u origin branch-name
. - In Github, browse you new branch, and click on the "Pull Request" icon.
- Enjoy a refreshing Coke and wait for us to merge your changes to the main branch.
Committing should be done as often as possible and as not in the 'master' branch as possible, keeping in mind that every commit should only include changes that are related. If you want to fix a small bug while working in another feature use stashing. The commit message should be something like the one in this blog:
With this in mind, commit messages should be(more or less) wrapped at 72 chars; have one line between paragraphs and be written in present tense. Keep the explanation technical, the idea is that other developers understand what you did an where without having to read the changes in every file.
Also is important to reference any issues that this commit has something to do with. If you know it introduced a bug, explain it and reference to the bug issue number, if that commit gives the program a new feature, reference the issue of that feature in the commit title.
Branching is good and should be done as often as necessary. Never work directly on the 'master' branch instead, create a new branch, work, and then push that branch back to the server and do a Pull Request.
Branches should be named after the thing they are going to be used for. 'exp' could be the name of a branch for trying out some stuff without messing with your development branch. If you are only taking care of an specific issue then you could name the branch after that issue and if you are doing a lot of programming, it could be named 'dev' or 'devel' and 'gui' if it's going to be used only for gui stuff.
Tagging is done to remember important stages in the program's history. In this project their are used almost exclusively for versions. Each important version number gets tagged. Exceptions apply if there's some important changes between versions.
If you wish to submit an issue or bug report please go to our Issues page.