Source Control Milestone¶
Due Date: October 23
You must watch the Git and Github lecture before working on this milestone.
The goal of this milestone is to ensure everything is set up correctly, and the whole team has started working together on their app using a shared codebase, with everything in git. The codebase does not need to do much, but it should at least include your framework. For example, if you are building an Android app then the codebase should be an Android app.
By this date you should have
Setup your github email correctly. Your most recent commits do not show a grey octocat avatar in github.
Have a team git repo in github with code that builds and runs (but probably does little else)
Every team member can check out the code, build it, and run it on their laptop.
Every team member has made a change to the code and pushed it to github.
Every team member has pulled in changes from other members.
Every team member has experienced and resolved a merge conflict.
For the merge conflict just have someone else in the time change some line in the code and push it. Then, before you pull, make sure you change that same line (to something else) and commit it. Then try to pull. You will see a merge conflict. Resolve it. Commit your changes. Push.
From here on out everyone in the team will be using git as part of their workflow. Remember, your final grade is largely based on your git commit log . It shows us everything you did.
Your project should have a
Readme.md on the root directory. For this class the
Readme is written for other developers, not for your end users. Namely , it
should be written so that the TAs and I have all the information need to compile
and run your code, but also so you can do so again when you have to re-do
everything on your new laptop.
Below is a template for a good
# Project Name This first paragraph should be a short description of the app. You can add links to your wiki pages that have more detailed descriptions. Your audience for the Readme.md are other developers who are joining your team. Specifically, the file should contain detailed instructions that any developer can follow to install, compile, run, and test your project. These are not only useful to new developers, but also to you when you have to re-install everything because your old laptop crashed. Also, the teachers of this class will be following your instructions. ## External Requirements List all the stuff the reader will need to install in order to get you app to run in their laptop. For example: In order to build this project you first have to install: * [Node.js](https://nodejs.org/en/) * [MongoDB](https://www.mongodb.com/) If possible, list the actual commands you used to install these, so the reader can just cut-n-paste the commands and get everything setup. You only need to add instructions for the OS you are using. ## Setup Here you list all the one-time things the developer needs to do after cloning your repo. Sometimes there is no need for this section, but some apps require some first-time configuration from the developer, for example: setting up a database for running your webapp locally. ## Running Specify the commands for a developer to run the app from the cloned repo. # Deployment Webapps need a deployment section that explains how to get it deployed on the Internet. These should be detailed enough so anyone can re-deploy if needed . Note that you **do not put passwords in git**. Mobile apps will also sometimes need some instructions on how to build a "release" version, maybe how to sign it, and how to run that binary in an emulator or in a physical phone. # Testing In 492 you will write automated tests. When you do you will need to add a section that explains how to run them. The unit tests are in `/test/unit`. The behavioral tests are in `/test/casper/`. ## Testing Technology In some cases you need to install test runners, etc. Explain how. ## Running Tests Explain how to run the automated tests. # Authors Your names and emails
Make sure your repo has a good .gitignore file. Most frameworks will automatically build one for you when you create a project, but you usually need to add more things to it. gitignore.io is a good place to find gitignore rules.
Coding Style Guide¶
Since you are about to start coding as a team, it is useful if your team also chooses a style guide to follow. You can choose one of Google's style guides, or find a different one. Add a link to your chosen guide from your Readme.md.
I recommend you use and automated code formatter like Prettier, black, swift-format, etc. Use the one your IDE supports. This way you do not have to think or do anything, the IDE does all the work.
Working Together Online¶
Everyone must write their own code, and make significant code contributions in this class.
But, you should also help each other as you code. You do this via your chosen chat application. Also, modern IDEs make it super easy to code together, checkout Code With Me: for JetBrains and CodeTogether: for VS Code, among others.
You have to be able to
- pull from the team repo,
- run application locally (laptop or emulator)
- commit to team repo,
- push to the team repo,
- merge your branch into master, via pull request or regular merge,
- and resolve a merge conflict.
Use Your IDE
Commits done on the github.com website do not count (but, do use Pull Requests). Practice by doing all the commits from your IDE.
A Pull Request is not a Merge
A Pull Request is a webpage at GitHub.com on which users can write comments and other stuff. A merge in git is a commit that merges two different branches.
Grade is 100 minus the total points lost, with minimum of 0. See grading scale in Syllabus. Points lost are:
|Deliverable||Points lost if you don't deliver|
|Username appears in git log on github repo.||100|
|Git/github email setup correctly to match.||50|
|Can build and run code on laptop. Show during our meeting, if I ask you to||100|
|User has Merge commit (two parents) in github log.||30|
|Has resolved a merge conflict (we can't actually check this AFAIK, so we will have to trust you did it)||30|