Workflow

Code Documentation

Comments are very important, specially for other team members to understand what you mean by your code.

We will have a documentation coverage system, which basically will tell us how much our project is documented.

Comments should start with a big letter, and space before the // and should end up with a dot[.]
comments are like propositions. When you write a block comments, the first line makes a resume of what you want to explain, then you put a break line and do the full description.

Examples of good comments:

/**
 * Mixin utility for form components.
 * 
 * This component does 2 things: 
 *  1. on submit it validate before so the form it self does not have to care about validation.
 *  2. on reset it clears the erros and then calls the reset function from the component.
 */
export default {
  methods: {
    /**
     * Validates the form and calls submit if there is no error.
     */
    validateAndSubmit() {
      ...
    },

    /**
     * Resets the form data from within the component and after clears the errors on next tick.
     */
    resetAndClearErrors() {
      // Executes DOM errors clearing only after vue updates it's model.  
      this.$nextTick(() => this.errors.clear());
    }
  }
}

Another example when you have params and returns in function.

/**
 * Checks if the same alert does not exist already in the queue.
 * 
 * @param alert {Alert} - the alert object which should be checked.
 * @return {Boolean} - true if alert is not in the queue yet, false otherwise.
 */
isAlertUnique(alert) {
  // Checks if the provided alert is not the same as the one which is displayed right now on the screen.
  if (alert.isEqualTo(this.currentAlert)) {
    return false;
  }
}

Git

EACH TEAM MEMBER MUST CLONE THE PROJECT.

Commits

The commits messages should be like this: [#IssueNumber] - Message

good example: [#33] - Fix security problem

Some Tips:

• a commit message always starts with a big letter and does NOT end in a dot [.](commits messages are like book titles)
  
• keep them as short and clear as possible (usually max 50 chars)
• last thing: The preference for present-tense, imperative-style commit messages which comes from git itself.

Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.

Branching

Before creating a new branch, make sure you are up to date with the master branch:

$ git fetch 

or to update all branches use:
$ git fetch --all 

then

$ git reset --hard origin/master

/!\ THIS WILL REMOVE ALL YOUR LOCAL UNSAVED FILES AND WILL TAKE THE STATE OF THE REMOTE BRANCH /!\

OR simpler use the GIT GUI tool (ex: Source tree)

Don’t ever work on the master branch. Let’s refresh your memories on how to make branches:

$ git checkout branchName

or if you want to check it out directly, then use:

$ git checkout -b branchName

Tip: Each branch should be made based on each feature, not page.
ex: 1-Project-Structure, where 1 is the Issue number and the rest of the text is a simple max 3 words description, each separated by a dash.

• When you make a branch, it is only created locally.

• You will continue to push your work on this local branch until you decided that the issue is solved.

• Now you have to rebase your branch on master branch and solve the conflicts (if needed); by doing this you will be sure that you have the last version of master.

• Next step is to squash all non important commits (means to combine multiple commits into one)

• Now you need to make your local branch to exist on your remote so your team members can see it. To do this, use the following command.

$ git push --set-upstream origin your-branch-name

• The last thing you have to do is the pull request (or merge request) which you do it on github

Recommended git interfaces software

• Source Tree
• GitKraken
• The default gitk & gitgui

Reset

• to reset the stat of a branch to another branch use git reset --hard <commit | branch> or use your gui tool to do this.

/!\ Pay attention reset hard will remove all your uncommitted changed, so alway do a git status before to be sure you are not losing data. (you can stash or temporary commit as WIP)

Rebase

• When you want to put your code on top of another code, you will use rebasing.
  rebase -i <commit | branch name> (Note: i stands for interactive After running this command, git will open an editor (usually vim); in the top of file you will have your current commits which are above the branch you want to rebase. There are multiple options you can play with, to rename commits, you can move them (reorder) you can squash (combine) and others.
• When you consider is ok, you can save the file (:x) and if everything is ok youur rebase will be done succesffully, otherwise if there are conflicts between your commits and the branch you are rebasing on, you will have to solve the commits and then run the command git rebase --continue.

Note: at any moment in the rebase when you consider you don't want to continue you can do git rebase --abort If you are inside the vim and you realize you don't want to rebase, you can delete all the commits and save the file. Git will not rebase if there is no commit present.