Our Vue application uses the MTG API to display Magic The Gathering cards and decks.
Our app allows users to search and see Magic cards and build decks with them.
| Functionality | Priority | Date |
|---|---|---|
| Search card | Must have | 2020-04-14 |
| Display card | Must have | 2020-04-14 |
| Build deck | Must have | 2020-04-17 |
| Display deck | Must have | 2020-04-17 |
| Display deck stats | Should have | 2020-04-18 |
| Save deck (session) | Should have | 2020-04-20 |
| Gallery of Art | Should have | 2020-04-20 |
| Project visuals | Nice to have | 2020-04-12 |
| Run in production | Nice to have | 2020-04-12 |
| Save deck through URL | Nice to have | 2020-04-23 |
| Dark theme | Nice to have | 2020-04-23 |
When developing the project, some rules are to be followed strictly.
Never commit against the master branch.
The master branch should only see merges from development branches.
When developing something, it must have its own development branch.
Development branches names must look like dev_<functionality-name>, where :
- the prefix
dev_never changes <functionality-name>is the name of the functionnality where words are separated by-
As such, when you start coding something, create a dev_somethin-you-code branch. Then code and commit against it. Finally, when the thing is ready for production, merge your branch in master.
Every commit must be linked to a ticket.
The Trello is here ; ideally, every ticket should have a commit and vice-versa.
Never commit without testing, even for a comment.
Always check if the project compiles and if the main functions plus what you just did works at least as well as it did before.
When fixing a big problem, a branch must be created.
Although the previous rule should offer protection against big bugs, shit happens. Would a big problem arise after merging into master, a fix branch should be created.
It should be named as fix_<broken-thing>.
While not being mandatory, those practices should be followed during the development process.
Try to include meaningful commit descriptions, for exemple by using the following keywords to start your descriptions.
| Keyword | Meaning | Exemple |
|---|---|---|
| Add | Create a functionality | Added chocolate to the cake project |
| Remove | Remove a functionality | Removed salt from the cake project |
| Fix | Fix an issue | Fixed chocolate pureness percentage (99 to 75) |
| Bump | Increase the version of something | Bumped cacao version (0.1 to 1.2) |
| Refactor | Code change | Refactored cake baking |
| Reformat | Refactor of formatting | Reformated Knife.Vue indentation |
| Optimize | Refactor of performance | Optimized cake serving |
| Document | Refactor of documentation | Documented cake baking process |
Although you should probably change one thing per commit, if you want to describe several changes in the same commit, break the changes in lines :
Added cake baking process
Documented cake baking process
Refactored cake serving component to use new cake baking process
Those lines should be relatively short (~100 characters, max).
Here is a handful of useful git commands :
| Command | Effect |
|---|---|
git add <file> |
Stages a file in the pending commit |
git commit |
Commits every staged file |
git push |
Sends local commits against the current branch |
git pull |
Gets every remote commits made |
git checkout <branch> |
Changes current branch to branch |
git checkout -b <new-branch> |
Creates new branch branch and switches to it |
git merge <branch> |
Merges branch into the current branch |
git status |
Shows the state of the local repository |
git clone <git-url> |
Clones the repository located at git-url locally |
git reset --hard |
Resets your local repository to last commit |
git diff [file] |
Displays changes between current version and last commit |
git shortlog -s -n |
Displays the list of contributors and the number of commits |
To change a file, the «standard» workflow would be :
git pullgit add folder/my-changed.filegit commitgit push
The standard workflow for a branch would be :
git pullgit checkout -b my-new-branch- do stuff and commit it
git checkout mastergit merge my-new-branchgit push
If you want aliases to spend less time typing in your console and more in your IDE, here is a list of aliases :
| Alias | Original command |
|---|---|
Gal |
git add --all && git status |
Gad |
git add |
Gco |
git commit |
Gps |
git push |
Gpl |
git pull |
Gck |
git checkout |
Gbr |
git checkout -b |
Gst |
git status |
Grs |
git reset --hard |
Gmr |
git merge |
Gac |
git add --all && git commit |
Gff |
git diff |
Glo |
Displays branches in console |
Gsl |
git shortlog -s -n |
Gbl |
Displays the number of lines per contributors |
The file is located in fronty/tools/git_aliases ; to add it in your bash, use the following command at the root of the project :
cp ./tools/git_aliases ~/.git_aliases && \
echo "[ -f ~/.git_aliases ] && . ~/.git_aliases" >> ~/.bashrc && \
source ~/.bashrcAll set ! Test it by using Gst, for instance.
| Alias | Original command |
|---|---|
Nrs |
npm run serve |
Nin |
npm install |
The file is located in fronty/tools/npm_aliases ; to add it in your bash, use the following command at the root of the project :
cp ./tools/npm_aliases ~/.npm_aliases && \
echo "[ -f ~/.npm_aliases ] && . ~/.npm_aliases" >> ~/.bashrc && \
source ~/.bashrc