Developer Contributing Guide

How to Contribute

Before reading, please refer to our CONTRIBUTING.md file. To develop lucky parking application, you'll need to first clone the repository on to your computer. For new Git users, see the Using Git section below.

OVERVIEW

Set up

Join the Repo Team
Using Git and Fork the Repo
Setting up your repository
Set up developer environment

Before you start working on an issue

Switch to new issue branch before you start making changes

After you've worked on your issue and before you make a pull request:

Check upstream before you push.

6a. No changes in the upstream repo

Or

6b. Conflicting changes in the upstream repo and how to resolve them

Okay. You're good to go!

Status updates
Complete the pull request

Forking and cloning the repository with proper security

Step 1: Become a member of the repository Team

In the lucky-parking slack channel, send your GitHub name to the Greg Pawin (or on the slack channel thread) and we'll add you as a member to the GitHub repository Team.

Once you have accepted the GitHub invite (comes via email or in your GitHub notifications), please do the following:

Mark your own membership public. How-to Guide
Setup two factor authentication on your account

Using Git

This section discusses some tips and best practices for working with Git.

Making changes, committing and pushing

Generally changes start on your local clone of your fork of this repository, in your own branch.
Commit your changes with a comment related to the issue it addresses to your local repository.
Push that commit(s) to your online GitHub fork.
From the hackforla repository, create a Pull Request which asks hackforla to pull changes from your fork into the main repository.
After the owner of the hackforla repository approves and merges your Pull Request, your changes will be live on the website.

Step 2: Fork the repository

In https://github.com/hackforla/lucky-parking, look for the fork icon in the top right. Click it and create a fork of the repository.

For git beginners, a fork is a copy of the repository that will be placed on your GitHub account url.

It should create a copy here: https://github.com/your_GitHub_user_name/lucky-parking, where your_GitHub_user_name is replaced with exactly your GitHub handle.

Note that this copy is on a remote server on the GitHub website and not on your computer yet.

If you click the icon again, it will not create a new fork but instead give you the URL associated with your fork.

Step 3: Setting up your repository

Step 3a. Clone your online repository to your local computer

For git beginners, this process will create a third copy of the repository on your local desktop.

First create a new folder on your desktop that will contain hackforla projects.

In your shell, navigate there then run the following commands:

git clone https://github.com/your_GitHub_user_name/lucky-parking.git

You should now have a new folder in your hackforla folder called lucky-parking. Verify this by changing into the new directory:

cd lucky-parking

Next, verify that your local cloned repository is pointing to the correct origin URL (that is, the forked repo on your own Github account):

git remote -v

You should see fetch and push URLs with links to your forked repository under your account (i.e. https://github.com/your_GitHub_user_name/lucky-parking.git). You are all set to make working changes to the lucky parking repo on your local machine.

However, we still need a way to keep our local repo up to date with the deployed website. To do so, you must add an upstream remote to incorporate changes made while you are working on your local repo. Run the following to add an upstream remote URL & update your local repo with recent changes to the hackforla version:

git remote add upstream https://github.com/hackforla/lucky-parking.git
git fetch upstream

After adding the upstream remote, you should now see it if you again run git remote -v :

origin  https://github.com/your_GitHub_user_name/lucky-parking.git (fetch)
origin  https://github.com/your_GitHub_user_name/lucky-parking.git (push)
upstream        https://github.com/hackforla/lucky-parking.git (fetch)
upstream        https://github.com/hackforla/lucky-parking.git (push)

If you accidentally cloned using the repository URL from the HackForLA Github (instead of the fork on your Github), then you can correct that with the following two commands:

Set your forked repo on your Github as an origin remote:

git remote set-url origin https://github.com/your_GitHub_user_name/lucky-parking.git

Add another remote called upstream that points to the hackforla version of the repository. This will allow you to incorporate changes later:

git remote add upstream https://github.com/hackforla/lucky-parking.git

Step 3b. Setting up the dev branch

As mentioned in CONTRIBUTING.md, developers should create their branches from the dev branch and make pull requests to the dev branch.

Create the dev branch

Fetch the most recent changes on the upstream remote

git fetch upstream

Create the dev branch off of the upstream remote branch

git checkout -b dev upstream/dev

When working on issues, create branches off of the newly created dev branch.

Update the dev branch with upstream changes

Update the branch with the latest changes using the following:

git fetch upstream
git checkout dev
git pull

Step 4: Setting up Developer Environment

Step 4a. Client Environment

change your current directory to client to install all the dependencies:

cd client
npm install

create your private Mapbox token:

open your browser and search for https://account.mapbox.com/
if you have a Mapbox account, sign in with your credentials. Or click on the link Sign up for Mapbox >
once logged in, click on + Create a token button
put lucky-parking in name input, keep default check boxes. Then click Create token to finalize the process

Click to see the Create token page

set environment variables find your lucky-parking token on https://account.mapbox.com/access-tokens/:

cd client/.envexample

copy token and paste in client/.envexample file on line 1 after REACT_APP_MAP_BOX_TOKEN=
change file name from .envexample to .env

Step 4b. Server Environment

change your current directory to server to install all the dependencies:

cd server
npm install

set environment variables ask team lead or fellow engineers for server side environment variables:

cd server/.envexample

copy credentials and paste in server/.envexample file
change file name from .envexample to .env

Step 4c. setup AWS EC2 credentials to access the parking citation data dev instance database

go to your .ssh folder:

cd
cd .ssh
touch lucky_ec2_dev.pem
nano lucky_ec2_dev.pem

ask team lead or fellow engineers for RSA private key, copy and paste into lucky_ec2.pem file
change the access permissions of lucky_ec2.pem:

chmod 400 lucky_ec2_dev.pem

You should be ready to work on issue from this point onward. If more assistance needed, feel free to reach out to team lead or fellow engineers.

Step 5: Work on an issue using git

Create a new branch for each issue you work on. Doing all your work on topic branches leaves your repository's main branch (named master) unmodified and greatly simplifies keeping your fork in sync with the main project.

a) Check current branch

The git branch command will let you know what branch you are in, and what branch names are already in use.

git branch

You will see a list of all of your branches. There will be a star (*) next to the branch that you are currently in. By default you should start on the dev branch.

Note: when you work on future issues, you must always be in the dev branch when creating a new branch.

If you are not currently in the dev branch, run the following command to return to it:

git checkout dev

b) Create a new branch where you will work on your issue

The git checkout command will create and change to a new branch where you will do the work on your issue. In git, the checkout command lets you navigate between different branches. Using the -b flag you can create a new branch and immediately switch into it.

To create a new issue branch, and switch into it:

git checkout -b 221-fix-logo-width

The text after the -b, in the example 221-fix-logo-width, will be the name of your new branch. Choose a branch name that relates to the issue you're working on. (No spaces!)

The format should look like the scheme above where the words are a brief description of the issue that will make sense at a glance to someone unfamiliar with the issue.

No law of physics will break if you don't adhere to this scheme, but laws of git will break if you add spaces.

When you've finished working on your issue, follow the steps below to prepare your changes to push to your repository.

c) Prepare your changes to push to your repository

Once you are done with the work on your issue you will push it to your repository. Before you can push your work to your repository, you will stage and commit your changes. These two commands are similar to the save command that you have used to in other programs.

Follow the instructions below to stage changes through the terminal.

-Use the git add command to stage your changes.
This command prepares your changes before you commit them. You can stage files one at a time using the filename.

Run the command:

git add “filename.ext”

-Use the git status command to see what files are staged.

This command will list the files that have been staged. These are the files that will be committed (saved) when you run the next command, git commit. Please be sure all your staged changes are relevant to the issue you are working on. If you find you have included unrelated changes, please unstage them before making this commit - and then make a new commit for the unrelated changes. (The commands for unstaging commits are provided in the output of your git status command.)

git status

-Use the git reset HEAD command to remove a staged file.

This command will remove a file that has been staged. This file will not be committed (saved) when you run the next command, git commit. This only works if the wrong files were added, but they were not yet committed. The file will be removed from the staging area, but not actually deleted:

git reset HEAD “filename.ext”

-Use the git commit command

This command saves your work, and prepares it to push to your repository. Use the -m flag to quickly add a message to your commit. Your message should be a short description of the issue you are working. It will be extremely helpful if other people can understand your message, so try to resist the temptation to be overly cryptic.

To commit your changes with a message, run:

git commit -m “insert message here”

Congratulations! You are now ready to push your work to your repository.

Step 6: Check upstream before you push

Before you push your local commits to your repository, check to see if there have been updates made in the main Lucky Parking repository. git fetch will check remote repositories for changes without altering your local repository.

git fetch upstream

Step 6a: No changes in the upstream repository

If you do not see any output, there have not been any changes in the main Lucky Parking repository since the last time you checked. So it is safe to push your local commits to your fork.

If you just type git push you will be prompted to create a new branch in your GitHub repository. The more complete command below will create a new branch on your copy of the repository, and then push your local branch there. The name at the end of this command should be the same as the name of the local branch that you created back in step 6, as in the example below:

git push --set-upstream origin 221-fix-logo-width

Step 6b: conflicting changes in the upstream repository

When you check the upstream repository, you may see output like this:

Fetching upstream
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 11 (delta 5), reused 7 (delta 4), pack-reused 0
Unpacking objects: 100% (11/11), 8.25 KiB | 402.00 KiB/s, done.
From https://github.com/hackforla/website

You can safely ignore changes in other issue branches, such as 221-fix-logo-width above. But if you see changes in master, you should incorporate those changes into your repository before merging or rebasing your issue branch. Use the instructions below to bring your fork up to date with the main repository.

Incorporating changes from upstream

Your fork of this repository on GitHub, and your local clone of that fork, will get out of sync with this (upstream) repository from time to time. (That's what has happened when you see something like "This branch is 1 commit behind hackforla:dev" on the github website version of your lucky parking repository.)

One way to keep your fork up to date with this repository is to follow these instruction: Syncing your fork to the original repository via the browser

Incorporating changes into your topic branch

To incorporate these updates from the main GitHub repository into your topic branch, you can 'rebase' your branch onto your updated master branch. NOTE you should only rebase if you have never pushed your topic branch to GitHub (or shared it with another collaborator).

git checkout 221-fix-logo-width
git rebase dev

If you receive warnings about conflicts, abort the rebase with git rebase --abort and instead merge master into your branch.

git checkout 221-fix-logo-width
git merge dev

Step 7: Status Updates

If you have not submitted a pull request make sure to write a weekly status update on your issue before the Monday meeting. Follow the format below and add pictures of any visual changes made to the site.

Progress: "What is the current status of your project? What have you completed and what is left to do?"
Blockers: "Difficulties or errors encountered."
Availability: "How much time will you have this week to work on this issue?"
ETA: "When do you expect this issue to be completed?"
Pictures: "Add any pictures of the visual changes made to the site so far."

Step 8: Complete the pull request

git push --set-upstream origin 221-fix-logo-width

Now create a new pull request to ask for your updates to be incorporated into the live web site. Go to https://github.com/hackforla/lucky-parking/pulls and click on "New pull request". Please rename your pull request something descriptive i.e. "Adding graph pages". Also, since your changes are not in the hackforla/lucky-parking repository, you need to click the "compare across forks" link in the first paragraph to make your repository and your new branch is available. Additionally, make sure to select the hackforla:dev branch as the branch to make your changes against. Make sure to include pictures of any visual changes made to the site and document your edits on the pull request so that the reviewer can understand the changes made. Review the changes that will be included in the pull request and, if it fixes a specific issue, include Fixes #140 in the pull request message so the issue will be closed automatically once your pull request is accepted and merged.

Once you have finished working on the issue you have chosen, commit the changes to your local branch (e.g. 221-fix-logo-width).

Important: After you completed your assignment and committed all of the changes, before moving onto your next issue and creating a new branch, you must leave your current branch and return to the dev branch. From there you can checkout into a new branch. (This ensures you don’t accidentally include the changes from your previous branch in your new branch).

Run the following command to return to the dev branch:

git checkout dev

From here, once your pull request is approved and merged you can pull the recent merge from the Hack For LA repository and delete your local branch:

git pull upstream dev
git branch -d <your-feature-branch>

Managing branches this way will keep the commit logs cleaner on the Hack For LA repository, versus merging your completed feature branches into your local repo.

Now you are all set to work on a new PR. Start over on Step 5.

Edits to pull request

If you find an error in your code or your reviewer asks you to make a change, please avoid editing your code directly from the pull request. Instead update it in your local branch first and then push it to your origin remote. This will update the original pull request.