Siwarga13: A Blade repository from agusanggit

💡 About Application

The web-based Rukun Warga Administration application is an application to learn more about the activities, benefits, and purposes as well as the importance of administation at RW. This application is made using Laravel version 10 and at least PHP ^8.1 so if at the time of installation or use there are errors or bugs likely due to versions of PHP that are not supported.

Tech Stack:

Software Requirement:

Git
Github
Composer 2.6.6
NodeJS <=20
PNPM >=8
PHP 8.1 or Laragon with bundling php 8.1
Postman or Thunderclient(VScode Extension)

🙇 Team:

Dyinastie Marchelina Puspitawening (System Analyst)
Emir Abiyyu Delanggra (UI/UX Designer)
Muhammad Rifky Harto Biantoro (Project Manager)
Syahrul Bhudi Ferdiansyah (Fullstack Developer)

🕙 Installation:

Open Address repository:

Repository
Fork repository:
- Search Fork in right corner of repo and click
- Click Create Fork in bottom, make sure you uncheck the Copy the master branch only
- If in your repository had fork from above repository address, your fork process is success
Clone fork repository:
```
git clone https://github.com/Your_Github_Address/Siwarga13
```
note: change "Your_Github_Address" with your actual address, like: SyahrulBhudiF or Rifki4w
Enter path folder repository:
```
cd Siwarga13
```

Install dependency:

composer install
composer update
pnpm install

Copy file .env.example to .env:
```
cp .env.example .env
```
Generate key:
```
php artisan key:generate
```
Create new Database Siwarga13 (match the database name in the file .env) in phpmyadmin or terminal:
```
mysql -u root -p
create database Siwarga13;
exit;
```
Migrate database:
```
php artisan migrate
```
Seeding database:
```
php artisan db:seed
```
run server:

a. Laravel Server:
```
php artisan serve
```
b. Laragon Server: Click Start in Laragon UI

c. Run Tailwind
```
pnpm run dev or pnpm dev
```
d. Run Queue Run Queue:
```
php artisan queue:work
```
Open browser and Access Localhost http://localhost:8000 (for Laravel Server) or http://localhost/www/Siwarga13 (for Laragon Server)

note: for steps 2-11 or any of steps that using bash or command syntax, you can do those bash syntax in your terminal or IDE-integrated terminal

🕙 Project Collaboration:

Sync Your Fork repository: You can click in middle top right in Your GitHub repository: Siwarga13
check your git status, specifically in branch:
```
git status
```
if branch isn't relate to your role, Change Branch to the related Your Role:
```
git checkout frontend
```
or
```
git checkout backend
```
or
```
git checkout dev
```
or
```
git checkout Your_Role
```
Pull code change, after fork synced in steps 1:
```
git pull
```
Crate your code change
Add to staging index your change:
```
git add .
```
Commit change:
```
git commit -m "commit message"
```
Note: for conventional commit message you can follow this rule:

Conventional Commit Messages

See how a minor change to your commit message style can make a difference.

ℹ️ git-conventional-commits A CLI util to ensure these conventions and generate changelogs

Commit Message Formats

Default
```
  <type>(<optional scope>): <description>
  _{empty separator line}
  <optional body>
  _{empty separator line}
  <optional footer>
  
```
Types
- feat Commits, that adds or remove a new feature
- fix Commits, that fixes a bug
- refactor Commits, that rewrite/restructure your code, however does not change any API behaviour
  - perf Commits are special
  - refactor commits, that improve performance
- style Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
- test Commits, that add missing tests or correcting existing tests
- docs Commits, that affect documentation only
- build Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
- ops Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
- chore Miscellaneous commits e.g. modifying .gitignore
Scopes

The scope provides additional contextual information.
- Is an optional part of the format
- Allowed Scopes depends on the specific project
- Don't use issue identifiers as scopes
Breaking Changes Indicator

Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint
- Is an optional part of the format
Description

The description contains a concise description of the change.
- Is a mandatory part of the format
  - Use the imperative, present tense: "change" not "changed" nor "changes"
  - Think of This commit will... or This commit should...
  - Don't capitalize the first letter
  - No dot (.) at the end
Body

The body should include the motivation for the change and contrast this with previous behavior.
- Is an optional part of the format
  - Use the imperative, present tense: "change" not "changed" nor "changes"
  - This is the place to mention issue identifiers and their relations
Footer

The footer should contain any information about Breaking Changes and is also the place to reference Issues that this commit refers to.
- Is an optional part of the format
  - optionally reference an issue by its id.
  - Breaking Changes should start with the word BREAKING CHANGES: followed by space or two newlines. The rest of the commit message is then used for this.
Examples
- ```
  feat: add email notifications on new direct messages
```
- ```
  feat(shopping cart): add the amazing button
```
- ```
  feat!: remove ticket list endpoint

  refers to JIRA-1337

  BREAKING CHANGES: ticket enpoints no longer supports list all entites.
```
- ```
  fix(api): handle empty message in request body
```
- ```
  fix(api): fix wrong calculation of request body checksum
```
- ```
  fix: add missing parameter to service call

  The error occurred because of <reasons>.
```
- ```
  perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog
```
- ```
  build: update dependencies
```
- ```
  build(release): `bump version to 1.0.0
```
- ```
  refactor: implement fibonacci number calculation as recursion
```
- ```
  style: remove empty line
```
Push change to fork and don't push to master like 'git push origin master', or you blocked by rule (always check branch with steps 2, so push will hit remote branch that role rule targeted):
```
git push
```
Do Pull Request from your fork to main repository to discuss the change with your team:
- Open your fork in your repository, if in there has notification to compare and pull request hit that button in there
- Create pull request from your fork to main repository branch master
(Optional) if when pull had problem with "merge using ort strategy", like merge commit with no actual changes make your work tree dirty, do this:
```
git config pull.ff only
```
Note: if there is error when pull, because git config pull.ff=only, do this:
```
git config pull.rebase false
```

🗒 Note :

If there are update change in your fork, always synced that, because you cannot push and crate pull request without that
When Checkout, Push or Pull, always check your git branch
Don't push to master with 'git push origin master' when add code change to GitHub
Always create Pull request like steps 8

agusanggit/Siwarga13

💡 About Application

Tech Stack:

Software Requirement:

🙇 Team:

🕙 Installation:

note: for steps 2-11 or any of steps that using bash or command syntax, you can do those bash syntax in your terminal or IDE-integrated terminal

🕙 Project Collaboration:

Conventional Commit Messages

Commit Message Formats

Default

Types

Scopes

Breaking Changes Indicator

Description

Body

Footer

Examples

🗒 Note :