-
Notifications
You must be signed in to change notification settings - Fork 28
Getting Started
If you don't already have a localhost installation you have a choice of many, but to keep things simple, we like to stick to these two:
Downloading and installing the latest WordPress version is the next step.
NOTE: We require that you run the following commands to configure your git installation in either Terminal or CMD (omitting $):
On Mac OSX/Linux:
$ git config core.filemode false; git config core.autocrlf input
On Windows:
$ git config core.filemode false; git config core.autocrlf true
This will hopefully prevent any future issues with spontaneous file permission changes.
Your next step is to install our github client of choice (requires that git is installed): SourceTree. Our entire team uses it and it is excellent when it comes to improving workflow! Also, there are some serious issues with the Official Github App and SourceTree offers much more control.
The second to last step is to clone the game-on master branch!
After logging in using your Github credentials, you can click the "+ New Repository" button and selecting the "Clone From URL" option from the drop-down menu. This will open a new menu which will have three fields, one for the SSH ([email protected]:TheMacLab/game-on.git) or HTTPS (https://github.com/TheMacLab/game-on.git) clone URL to TheMacLab/game-on:master, one for the destination of the cloned repository (you'll have to create an empty folder in your /wp-content/plugins/ directory named game-on, and navigate to it), and one for the name of the repository which will default to whatever the name of the destination folder is (it is best to leave it be).
If everything went according to plan, after you hit "Clone" you should see an item appear in your repository list. Opening it up (either right clicking and hitting "Open" or double-clicking will do the trick) will present you with your git workspace.
The master branch:
The master branch is where you will store only the most recent stable version of Game-On. This is the branch that you will be using to base your other branches off of, the majority of the time.
The dev branch:
Your development branch (named with the format dev-{first_name_or_username}, for example, dev-forest) is where you will merge together your changes before pushing them to your fork, which we'll get to in the next section.
The feature|hotfix branches, our most common changes to Game-On are bug fixes and new features. The most reliable way to build your work environment is to section off your changes into separate branches. By keeping everything separate, you're able to minimize damage caused by corrupted code, and allows for much more maneuverability when merging changes. SourceTree does the favor of grouping branches together into folders in the branch list on the left-hand side-bar, when a branch is named like so: hotfix/permission_fix. Writing the name like a path, allows you to neatly organize your changes, and branching is what git is all about!
To create your development branch, click the "Branch" option on the top bar, near the right side. This will open a drop-down menu and allow you to name the branch that you intend to create. Name it dev-{your_name}, all lower-case, with your name as one word.
You should read to the end of this step, if you don't know about how to use git. But if you'd like to skip ahead, you still need to fork Game-On on Github.
Here is an excellent resource to learn everything you could possibly want to know about git, that is the Git Pro Book.
But to just get you started, here's a little cheatsheet:
Branches act like separate versions of your code (thus the term versioning software), isolated from the rest so that you can freely move back and forth between tasks.
Checkout is a process of your local repository's HEAD to a different branch, when used on branches. This allows for us to swap between branches. When used on files or directories, the checkout command allows us to basically reset the changes on a file to what they were before we started editing them (this really only applies to using git in the Terminal/CMD, but is still useful to understand).
Pushing is a process of updating your changes from a local repository to a remote one. For instance your fork.
Pulling is the process of, you guessed it, pulling your changes from a remote repository to your local repo. An example would be updating your master branch with the most recent release on TheMacLab/game-on.
Commits are logs of your changes and are made by adding changes to the index (the to commit list).
Adding/Removing files is necessary to create commits. Files cannot be commited if they haven't been first added to the index. Note that "removing" files using SourceTree actually deletes the files instead of simply checking them out. So, use the "reset this file..." option when attempting to reset changes on an unstaged file.
Open the TheMacLab/game-on main repository page on Github. Then click the fork button in the upper right-hand corner (not the numbers!) and Github should begin creating your remote repository for you. After your fork has been created, notice the clone URL field at the bottom of the right side-bar, above the "Clone in Desktop" and "Download ZIP" buttons. Copy the URL and then switch back to your repo in SourceTree. On the left side-bar, under the branch list, you should see a list of "Remotes". Right click the "Remotes" label and select "New Remote".
You will be presented with another drop-down, the first two fields are the most important. The first is what your remote will be called, for simplicity and consistency, call it "fork". The second field will be where you paste the URL that you just copied. After hitting "Ok", you've successfully linked your fork to your local repository and now you can easily push to it!
-
The key to any projects success is communication, so when writing an email (or making a pull request or issue) that has to do with a bug, a new feature, or simply a question, make sure that everyone is included. If someone isn't on the same page as everyone else, that leads to unnecessary work being done, and we don't want that!
-
Google, the MDN Network, PHP.net, Stackoverflow, WordPress.org Codex are only a few of the websites that are extremely helpful to solving problems.
-
Use error reporting to your advantage. Safari, Chrome, and Firefox have very robust developer tools to deal with errors in Javascript code as well as uncovering silent AJAX problems. MAMP and XAMPP come with access to PHP and MySQL error logs (
XAMPP/logs/), use them. -
When testing, always assume the worst possible scenario and test it. Never assume that a user won't act in an unusual way, they will.
-
Never push directly to
TheMacLab/game-on:masterwithout an "OK" from at least one other coder, and always double check your work. When in doubt, push to the dev branch on your fork, and send the download link to other team members (and then keep pestering them until they test your changes). -
Make frequent commits and back-up your repository a lot.
That's about it. If you made it this far, congrats! Make sure to read up on our syntax rules here.
Good luck and happy coding! ~ @foresthoffman and the Mac Lab team