GitHub Guide
Last updated
Last updated
For our web development and blockchain projects, we typically use the following structure:
src/
: Contains the main source code for the web application
public/
: Stores static assets and the main HTML file
contracts/
: (For blockchain projects) Stores smart contract code and tests
scripts/
: Contains build and deployment scripts
config/
: Holds configuration files
docs/
: Project documentation
tests/
: Unit and integration tests
Format:
Components:
<type>
:
feature
: New features or enhancements
bugfix
: Bug fixes
hotfix
: Urgent fixes for production
chore
: Routine tasks and maintenance
<TICKET_NUMBER>
:
The identifier from our project management tool (e.g., TICKET-1234
)
<short-description>
:
A brief, kebab-case description of the work (e.g., add-user-authentication
)
feature/TICKET-1234-add-user-authentication
bugfix/TICKET-5678-fix-login-error
hotfix/TICKET-9012-patch-security-vulnerability
chore/TICKET-3456-update-dependencies
Identify the ticket number from our project management tool
Determine the branch type based on the task
Create the branch using the following format:
We use the following structure for commit messages: Ticket Number | Name | Description
Examples:
TICKET-1234 | JohnDoe | Add user authentication feature
BUG-1234 | JohnDoe | Fix login issue
TASK-1234 | JohnDoe | Update API endpoint for retrieving user details
Note: You will get the ticket number from the Hubstaff Kanban board.
When your work is ready for review, create a pull request (PR) following these guidelines:
Title: Use the format [TICKET-NUMBER] Brief description of changes
Example: [TICKET-1234] Implement user authentication feature
Description: Include the following sections:
Summary of changes
How to test
Screenshots (if applicable)
Any additional notes or concerns
Reviewers: Assign at least one team member to review your PR
Labels: Add appropriate labels (e.g., 'bug', 'feature', 'documentation')
Link to Ticket: Include a link to the related ticket in the PR description
Branch: Push your feature branch and create a PR to merge into main
Checks: Ensure all checks pass before merging
Reviewers should provide constructive feedback within 24 hours
Address all comments and make necessary changes
Once approved, merge the PR using the squash and merge strategy
Staging: All merged PRs are automatically deployed to the staging environment
Production: After thorough testing on staging, create a release PR to merge develop into main
Keep commits atomic: Each commit should represent a single logical change
Write clear commit messages: Follow the commit message structure outlined above
Regular updates: Pull from the main branch frequently to stay up-to-date
Code style: Adhere to the team's agreed-upon coding standards and use linters
Documentation: Update relevant documentation as part of your changes
Create a new branch:
Push to a remote branch:
Pull the latest changes:
Merge a branch:
Delete a branch:
Create a new PR:
Stash changes:
Apply stashed changes:
View commit history:
Undo last commit (keeping changes):