Displaying chess opening popularity for a Computer Science Web development course at Stellenbosch University
READ THIS AND DO BEFORE ANYTHING ELSE!!
Before you do anything in this project, it is important to sort out some gerrit admin. Please follow EVERY one of the following steps:
$ git config --global user.email "firstname.lastname@example.org" $ git config --global user.name
$ git config --global core.editor vim
$ git clone ssh://<username>@codebreakers.co.za:29418/visiochess $ cd visiochess
$ scp -p -P 29418 <username>@www.codebreakers.co.za:hooks/commit-msg .git/hooks
Setting up on Ubuntu/Debian, a simple "sudo apt-get install git"
should do it. If you are adventurous, it can be built from source.
For non-debian based system, it should be available in whatever packagemanager your system uses.
Now, git is a version tracking system, that keeps a complete copy of the entire project, including history, on each user's system. Useful, in case of server's crashing. (Ours is based in Amsterdam at the moment, so we should be safe against Eskom, if they feel like load shedding).
OK. So if you clone a repository from a server, you have the latest version of the entire project and its history. Big whoop. You list the contents of the directory, and see the following:
Say now, you want to edit this game, so that the main character has a new superpower, that spouts fire from his/her belly button. To do this, say you end up editing humxn.js and main.js. Once you are happy with this new feature, you run
$ git status
This will output a lot of stuff, amongst others
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: humxn.js modified: main.js
This means that at this point, your changes might be in working order, but unless you take further action, they will not be added to the project, and possibly lost. To prevent such a catastrophe, you need to commit the changes.
Committing is a two step process. First, changed files need to be staged. This is an in between state, and provides an easy way to not accidently commit unnecessary files.
$ git add humxn.js $ git add main.js $ git status
Now, your output should be
Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: humxn.js modified: main.js
If you are happy that these are indeed the files that you edited, and you want to now commit these changes into the project, you can proceed with the second and final step of committing.
$ git commit -m "A nice descriptive message here"
Each commit is accompanied by a message such as above, indicated with the -m flag. without the flag and message, you will be taken to your text editor to set one, but just including it in the command is much easier.
All changes to this point have been limited to your own system. To get this onto the central repository on the server, one needs to push. To "save" minor changes on the system,
$ git push -u origin HEAD:sandbox/<username>/branch_name
and if you want to push code for review,
$ git push -u origin HEAD:refs/for/master
The "master" is the branch being targeted and can also be some other branch name.
This is a nice intro, and will be expanded more, as there is more to know, but for now, this is a crash course on the basics.
Summarize changes in around 50 characters or less More detailed explanatory text, if necessary. Wrap it to a max of 72. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here If you use an issue tracker, put references to them at the bottom, like this: Resolves: #123 See also: #456, #789
Use the imperative mood in the subject line
Imperative mood just means "spoken or written as if giving a command or instruction". A few examples:
The title of your subject line should fit into the following phrase:
“If this PR is merged it will “
Add a new home screen “if this PR is merged it will” add a new home screen.
OK, first assumption: You were sent a whatsapp that gave you a unique password, to access the gerrit review interface. There you would have been prompted to give your SSH public key. Do this, for git cloning purposes. If you are uncertain, you may skip this step, and just use http for cloning instead.
If you do not want use ssh, that is fine. Then, after loggin in, click the drop down arrow below your name in the Gerrit GUI interface, and go to settings. From there, go to the HTTP Password tab on the left hand side. Click "Generate Password. Copy that password that gets displayed.
I also assume that you would have cloned the repo by now. The command was:
$ git clone ssh://<username>@www.codebreakers.co.za:29418/visiochess
$ git clone http://www.codebreakers.co.za:8080/p/visiochess Cloning into 'visiochess'... Username for 'http://www.codebreakers.co.za:8080': $<username> Password for 'http://<username>@www.codebreakers.co.za:8080':
where <username> is your username on gerrit, and incidentally, also your google username. The password is the one generated in the user settings.
An ssh example would be
$ git clone ssh://email@example.com:29418/visiochess
It is vital that you have registered and added your ssh public key, otherwise, cloning will simply not work.
Now, a quick summary on how to make make and send changes (patches) for review:
You will of course only have to clone once. Unless you delete the entire project directory, you should not have to do so again.
Whenever you start new work on your game level, no matter how small, always checkout the master branch and pull (from a clean working directory). This ensures that you are on the latest version and minimizes potential merge conflicts in git.
$ git checkout master $ git pull origin
Then create and checkout a branch, naming it somewhat descriptively.
$ git checkout -b my_branch
Note the -b flag, that tells git to actually create this branch.
Do your coding, committing regularly. Once you are ready to submit for review, you need to first rebase and squash all your commits together in a single review commit. Take note that the review commit is again in a newly created branch. The branch is created while my_branch is checked out, so it also contains all the latest changes at this point
$ git checkout -b my_branch_review
Next, the rebasing and squashing, done with the --interactive flag
$ git rebase master --interactive
Alternatively, these two steps may be replaced with
$ git checkout -b my_branch_review $ git reset --soft origin/master $ git commit -m "A single commit message"
This will run your preferred text editor according to git, for which I strongly recommend vim. Generally, the top line can be kept as "pick", and the rest changed to f or s. When you are done, save and quit.
Once the rebasing and squashing is done, the commit can be pushed to the server for review:
$ git push origin my_branch_review:refs/for/master
In the GUI environment online for gerrit, set someone to review your code.
Suppose your patch has some issue, that a reviewer points out that needs fixing first. If you still have the you commited, you may simply just check it out. If not, you need to fetch it.
First, ls all the commits on gerrit for the project with
$ git ls-remote From ssh://firstname.lastname@example.org:29418/visiochess.git d5a54cc7a7b889a2052ed9dc92dc82a62e0f6591 HEAD 44f45cb46d84f1f7c2e0028a8d7f03af360bb88a refs/changes/18/18/1 . . .
The pactch you are interested will be amongst the ones of the form "refs/changes/*/*/*". Note, the numbers in the places of the asterisk will correspond to the number in the browser url when viewing the commit in the browser GUI interface.
Once the commit has been identified, fetch it and check it. Say you want to view the "refs/changes/18/18/1" patch:
$ git fetch origin refs/changes/18/18/1 && git checkout -b some_branch_name FETCH_HEAD
Now, you will have a new branch with the name you provided, in this example, "some_branch_name", with the patch in question. You make the changes needed, stage them again with "git add" and then commit them with "git commit --amend". Lastly, the new patch is commited to Gerrit
$ git add -u $ git commit --amend -C HEAD $ git push origin HEAD:refs/for/master
The "-C HEAD" flags tells git to use the same commit message again.
For now, all testing can easily done by a node.js script.
$ sudo apt-get install nodejs npm $ sudo npm install express $ sudo npm install http-server -g $ sudo npm install -g yo generator-phaser-official
Run the server locally using:
nodejs src/SimpleServer.js server
Don't judge the very simple csv. It was hastily crafted over Christmas.