Getting Started

Cloning and Developing On the Site Locally

Git and GitHub

To work with the website, make sure to have a GitHub account and Git installed.

Cloning and Pushing

Clone the repository to your local machine by running:

git clone https://github.com/HackAtUCI/irvinehacks-site-2024.git

When pushing to the repository, the following may occur:

  • Your changes are pushed properly and appear on GitHub: no further setup needs to be done!

  • Git prompts you for a username and password: you can supply your GitHub username for the username and a personal access token for the password.

Branches

When the team is working on their own issues or new features, we each create separate branches so that one person's work does not conflict with another's.

To create a new branch, click "create a branch" on the bottom right and enter a branch name.

At Hack at UCI, we tend to name our branches by stating the type of change, followed by a forward slash, and then the name of the change itself. For example, the above issue could have a branch name of setup/pre-commit-hooks because this issue is related to setting up the development environment and pre-commit hooks is the topic of the issue.

Pull Requests

A pull request facilitates the merge of a branch dedicated to resolving an issue into the main production branch. It allows other team members to review the code in the branch and provide feedback on any changes.

An example of a comment on a pull request related to the administration portal

The tech team has added automated feedback for code formatting and issues with types, along with a preview deployment system, so developers can look at the changes in the branch as if they were already deployed to production. We deploy these previews to Vercel, which you can read more about in Preview and Production Deployments.

An example of the preview deployment at work

One thing to keep in mind when creating issues is to avoid making large scope issues. Otherwise, a pull request for a branch to resolve this issue can become unnecessarily large due to both automated comments and comments from other developers on the team.

For example, a task for creating new page should not be allocated only one issue, but rather split into several smaller issues, unless the page is small enough.

You can create a task list to keep track of the changes related to the page.

Last updated