Kaziflow - (client)

Task / Team / Project / Employee tracking tool

Quick Installation

### Clone the git repository
git clone https://github.com/InnocentWahome/kaziflow-client.git

### Setup environment variables
cp .env.example .env

### Install project dependencies
npm install

### Initialize development server
npm run serve

### Run production
npm start

Author

• [Innocent Maina](mailto: innocentwahome@gmail.com)

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing.

Prerequisites

• Node
• npm

Installing

First clone the repository from github by running the following command:

git clone https://github.com/InnocentWahome/kaziflow-client.git

Install all the required modules:

npm install

Running the Application

You can go ahead and run the application using npm command:

npm run serve

Testing

To run the unit test, run the following command

npm run test:unit

Some Git rules

There are a set of rules to keep in mind:

• Perform work in a feature branch.

  Why:

  Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. read more...

• Branch out from develop

  Why:

  This way, you can make sure that code in master will almost always build without problems, and can be mostly used directly for releases (this might be overkill for some projects).

• Never push into develop or master branch. Make a Pull Request.

  Why:

  It notifies team members that they have completed a feature. It also enables easy peer-review of the code and dedicates forum for discussing the proposed feature.

• Update your local develop branch and do an interactive rebase before pushing your feature and making a Pull Request.

  Why:

  Rebasing will merge in the requested branch (master or develop) and apply the commits that you have made locally to the top of the history without creating a merge commit (assuming there were no conflicts). Resulting in a nice and clean history. read more ...

• Resolve potential conflicts while rebasing and before making a Pull Request.

• Delete local and remote feature branches after merging.

  Why:

  It will clutter up your list of branches with dead branches. It ensures you only ever merge the branch back into (master or develop) once. Feature branches should only exist while the work is still in progress.

• Before making a Pull Request, make sure your feature branch builds successfully and passes all tests (including code style checks).

  Why:

  You are about to add your code to a stable branch. If your feature-branch tests fail, there is a high chance that your destination branch build will fail too. Additionally, you need to apply code style check before making a Pull Request. It aids readability and reduces the chance of formatting fixes being mingled in with actual changes.

Writing good commit messages

Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. Here are some rules of thumb (source):

• Separate the subject from the body with a newline between the two.

  Why:

  Git is smart enough to distinguish the first line of your commit message as your summary. In fact, if you try git shortlog, instead of git log, you will see a long list of commit messages, consisting of the id of the commit, and the summary only.

• Limit the subject line to 50 characters and Wrap the body at 72 characters.

  why

  Commits should be as fine-grained and focused as possible, it is not the place to be verbose. read more...

Built with

• vue js