Repository for Stylishly REST API.
Create a dedictated Stylishly
directory and cd
into it:
$ mkdir stylishly && cd stylishly
Create a virtualenv:
$ python3.6 -m venv ./env
$ source ./env/bin/activate
You can set your environment variables in the virtual environment activate
script file, so they get loaded upon activation:
$ open ./env/bin/activate
In the activate
script file:
# This file must be used with "source bin/activate" *from bash*
...
export ENV_VAR=VALUE
...
Clone this repository and cd
into it:
$ git clone git@github.com:lezoudali/stylishly-api.git && cd stylishly-api
Install python dependencies:
$ pip install -r requirements/all.txt
Install PostgreSQL. You can achieve this with homebrew:
$ brew install postgresql
Start PostgreSQL
once it's been installed:
$ psql
In the PostgreSQL
command prompt, create your development database, connect to it and create the uuid-ossp
extension:
postgres=# CREATE DATABASE stylishly-dev;
postgres=# \c stylishly-dev;
postgres=# CREATE EXTENSION "uuid-ossp";
Be sure to set the following enviroment variables:
export STYLISHLY_DB_DATABASE="stylishly-dev"
If your PostgreSQL database requires a username and password, then set the following variables:
export STYLISHLY_DB_USERNAME=<username>
export STYLISHLY_DB_PASSWORD=<password>
Perform similar steps to setup your test database, except replace the followings:
stylishly-dev
=> stylishly-test
STYLISHLY_DB_DATABASE
=> STYLISHLY_TEST_DB_DATABASE
STYLISHLY_DB_USERNAME
=> STYLISHLY_TEST_DB_USERNAME
(if needed)
STYLISHLY_DB_PASSWORD
=> STYLISHLY_TEST_DB_PASSWORD
(if needed)
- Checkout
dev
branch:git checkout dev
. - Pull the latest state of the
dev
branch on the remote:git pull origin dev
. - Create your bugfix or feature branch:
git checkout -b feature/my-cool-feature
orgit checkout -b bug/wrong-validation-logic
. - Push your branch to the remote:
git push -u origin feature/my-cool-feature
. - Open a pull request from your branch to
dev
branch. Later when it's ready for review, comment there and ask for code review. - Work on your branch, make commits (and pushes if you want).
- When you're done you can have a lot of commits with some weird messages where you just commit intermediate state of your progress. So sometimes it's good practice to squash them.
Say you worked on your branch and created 5 commits.
Then just do
git rebase -i HEAD~5
. The default editor (for example I have vim as default) will open a list of commits. leavepick
for first and replacepick
withsquash
for others. Then save and quit the editor (:wq
in vim). After this, another editor will open to edit the commit message. Make sure your commit messages describe the changes you've done and also the tricky points. This is very important for history. - If you did squash, push your branch using
git push -f
. - Now you can comment in your pull request something like
Ready for code review
. Or@username seems it's done. Could you please review?
- If reviewer asked to apply some changes, the commits with fixes in most cases should be squashed as well before merge.
- When reviewer said that you can merge, squash and merge. Then delete your working branch on the remote.
Also pull
dev
from remote and remove your local working branch that's already merged intodev
.