Overview
Recruitment
Standards
Git Setup
Git Usage
 
Compile

Forking

Before you can start coding on one of our plugins you will need to create you own fork and setup the project in your IDE. The below example is for forking MassiveCore.

Go to https://github.com/MassiveCraft and click on the project. That would take you to https://github.com/MassiveCraft/MassiveCore. Click the fork button.

Copy the “SSH clone URL” on your own fork page. Open your git terminal and go to the Eclipse workspace directory where all projects are stored. Then execute the following commands to download and setup your fork.

Open Eclipse and use the “New Java Project” main menu option: File New Java Project. Enter “MassiveCore” as project name. Since the folder already exists you can click the “Finish” button immediately. Open project build path and add your external spigot-api.jar. If you also add spigot.jar (not required for MassiveCore), make sure spigot-api has the highest build path priority.

Branching

Before you start coding you should create a new branch. We discourage working on the master branch because you might want to work on multiple features at once. Each feature should have it’s own branch with a single commit to keep things separated and avoid confusion.

Committing

When you have made your changes and think they are ready to be pulled you should create a commit.

Rebasing

While you work on your commit other commits are probably pulled into upstream, leaving your work a bit outdated. So before requesting that your commit be pulled you should “rebase” which is a form of update. Rebasing is painless most of the time but sometimes you will have to do some manual conflict resolution if another commit changed the same files as yours.

Requesting

We do not create actual pull requests on GitHub. Just paste the GitHub website URL for the branch in the tech staff Skype chat. Make sure you paste the branch URL and not the commit URL. The commit URL gets outdated upon amending the commit with changes. The branch URL will however stay updated even after amending.

Amending

The first version of your commit will probably not get accepted. You will get feedback and should make further changes. When you made those changes you should amend your previous commit rather than creating a new one. You should only have one commit per branch.

If you have already made multiple commits, rather than amending, you will have to squash those commits into one using “interactive rebasing”. These two guides should cover you:

  1. http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
  2. https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/

Cleanup

When your commit has been pulled it’s time to do some cleanup. This involves updating and resetting the master branch as well as deleting the branch your created both locally and remotely.