spacelabdev/fund_lab_force

## SpaceLab's FundLab Force

Getting Started

To get a local copy of the project, follow these steps.

Prerequisites

Make sure you have the latest npm package installed

npm install npm@latest -g

Make sure you have the latest version of node installed.

We recommend using a node manager to switch between node versions.
If you are on Mac or Linux you can install nvm to manage your node versions. For windows, you can use nvm for Windows

nvm install 18.16.0 (or higher)

nvm use 18.16.0 (or higher)

Installation

Clone (or fork) the repo

git clone https://github.com/spacelabdev/fund_lab_force

Install NPM packages
```
npm install
```
Spin up the Project
```
npm run dev
```

General Workflow

In general, the flow goes like this:

Update your local version of main: (git pull) (in your main branch)
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit some Changes (git commit -m 'Add some AmazingFeature')
Rebase your branch to have the latest updates from main (git rebase origin main)
Push your branch to the remote (git push origin feature/AmazingFeature)
Open a Pull Request and include a screenshot of the feauture you worked on

Never push changes directly to main, always use a feature branch!

Delete your branches once they're merged.

Git Branching, Merge vs. Rebase, and Pull Requests

When fixing a bug or creating a new feature, please use a separate branch called a feature branch.

Creating a Feature Branch

To check out a feature branch:

git checkout -b feature/amazingFeature

Branch Naming Conventions:

feature/nameOfFeature: New feature or comoponent
enhancement/nameOfFeature: Enhancement of exsisting feature or component
hotfix/nameOfBug: Quick bug or update

Merge vs. Rebase

Merge and rebase are two strategies for integrating branches in git.

Merge:

Easiest option
Non destructive, keeps the original commit history of both branches
In projects with lots of developers using merge can create a messy commit history
git rebase origin main

Rebase:

Alters the commit history, gives the ability to squash commits
Destructive, should only be used on private branches
When used correctly can creates a neat commit history
git merge origin main

Use rebase ONLY when you are working on a private branch, meaning you are the only developer making changes to the branch, and you haven’t created a PR yet. You should rebase your feature branch every time before creating your PR, or if there are changes that have been made to main that you need to incorporate in your branch.

Use merge when on public branches, meaning there are multiple people making changes to the branch, or you have already submitted a PR and need to update something in the code.

To reset your branch to match the remote you can run:

git reset --hard origin/"Your branch"

Submitting a Pull Request

PR's should be submitted when your feature/bug-fix is complete and has been tested.

Before submitting a PR, run through this code checklist:

Remove any console.logs and unnecessary comments in your code
Add alt tags to all images, labels to all inputs, and check that your html is semantic
Make sure styles are properly nested so that other parts of the site aren't affected
Test your feature/page on mobile/tablet/desktip in dev tools and check that it doesn't break
Check that Webpack compiles without warnings, resolve any errors before pushing
Rebase your branch with main and check that it is up to date

Once you complete the checklist, open a PR and include a short description of what you accomplished. If you built a new feature, include a screenshot of the UI.