-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This update includes guides on Git setup, basic commands, club-specific guidelines, and useful resources for club members.
- Loading branch information
1 parent
97810e9
commit 68201d3
Showing
11 changed files
with
7,103 additions
and
6,542 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
{ | ||
"label": "Git Documentation", | ||
"position": 1, | ||
"link": { | ||
"type": "generated-index" | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,118 @@ | ||
--- | ||
sidebar_position: 5 | ||
--- | ||
|
||
# Advanced Git Workflows | ||
|
||
In the SFU Open Source Development Club, we follow a streamlined Git workflow to facilitate collaboration and maintain code quality. This document outlines our workflow for managing features, bug fixes, and issues. | ||
|
||
## Workflow Overview + Detailed Steps | ||
|
||
1. **Branch Creation**: Create separate branches for each new feature, bug fix, or issue. | ||
2. **Development**: Implement changes on the designated branch and commit changes with clear and descriptive messages. | ||
3. **Pushing Changes**: Push the branch to the remote repository. | ||
4. **Create Pull Request**: Open a pull request for review and merging. | ||
5. **Code Review and Merging**: Conduct code reviews and merge changes once approved. | ||
6. **Pull the Latest Changes**: Pull the latest changes to ensure your local main is up to date.. | ||
|
||
|
||
## 1. Branch Creation | ||
|
||
When starting work on a new feature, bug fix, or issue, create a new branch off the `main` branch. | ||
|
||
- **Naming Convention**: Use the following naming convention for branches: | ||
- **Features**: `feature/your-feature-name` | ||
- **Bug Fixes**: `bugfix/your-bugfix-name` | ||
- **Issues**: `issue/your-issue-name` | ||
|
||
#### Example Commands: | ||
```bash | ||
# Checkout the main branch | ||
git checkout main | ||
|
||
# Pull the latest changes | ||
git pull origin main | ||
|
||
# Create a new branch for a feature | ||
git checkout -b feature/new-feature | ||
``` | ||
|
||
## 2. Development | ||
|
||
Make changes in your branch. Ensure you frequently commit your work to save progress. | ||
```bash | ||
# After making changes | ||
git add . | ||
git commit -m "implement new feature" | ||
``` | ||
|
||
## 3. Pushing Changes | ||
|
||
Once you have completed your work and are ready to share it, push your branch to the remote repository. | ||
```bash | ||
git push origin feature/new-feature | ||
``` | ||
|
||
## 4. Create a Pull Request | ||
|
||
After pushing your branch, create a pull request (PR) in the repository on GitHub | ||
- **Description**: Provide a clear description of the changes made, referencing any relevant issues. | ||
|
||
|
||
## 5. Code Review and Merging | ||
|
||
Once the pull request (PR) is created, it is essential for team members to review the changes. This process ensures that the code meets the club's standards and that no issues are overlooked. | ||
|
||
### Review Process | ||
- At least one team member should carefully read through the code changes in the PR. | ||
- Consider the following during the review: | ||
- Code quality and readability | ||
- Functionality and correctness of the implemented changes | ||
- Adherence to the club's coding standards | ||
- Any potential bugs or issues that need to be addressed | ||
|
||
### Addressing Feedback | ||
If feedback is provided during the review, make the necessary changes to your branch. You can do this by: | ||
1. Making the changes in your local branch. | ||
2. Committing the updates with clear messages. | ||
3. Pushing the changes to the remote branch. | ||
|
||
#### Example Commands: | ||
```bash | ||
# Make changes in your code editor | ||
git add . | ||
git commit -m "address review comments" | ||
git push origin feature/your-feature-name | ||
``` | ||
|
||
### After Approval | ||
|
||
Once the PR has been approved by at least one team member: | ||
1. **Merge the Pull Request**: Merge the changes into the main branch. | ||
2. **Delete the Feature Branch**: If the feature branch is no longer needed, delete it to keep the repository clean. | ||
|
||
#### Example Commands to Delete the Local Branch: | ||
```bash | ||
# Delete the local branch | ||
git branch -d feature/your-feature-name | ||
``` | ||
|
||
#### Example Commands to Delete the Remote Branch: | ||
```bash | ||
# Delete the remote branch | ||
git push origin --delete feature/your-feature-name | ||
``` | ||
|
||
|
||
### 6. Pull the Latest Changes | ||
|
||
After merging, ensure your local main branch is up to date. | ||
|
||
```bash | ||
# Checkout main branch | ||
git checkout main | ||
|
||
# Pull the latest changes | ||
git pull origin main | ||
``` | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,112 @@ | ||
--- | ||
sidebar_position: 3 | ||
--- | ||
|
||
# Basic Git Commands | ||
|
||
Git provides a variety of commands to manage your version control efficiently. Below are some of the most commonly used Git commands along with their descriptions. | ||
|
||
## 1. Initializing a Repository | ||
|
||
To create a new Git repository, navigate to your project directory and run: | ||
|
||
```bash | ||
git init | ||
``` | ||
|
||
## 2. Cloning a Repository | ||
|
||
To create a copy of an existing Git repository on your local machine, use: | ||
```bash | ||
git clone <repository-url> | ||
``` | ||
|
||
|
||
## 3. Checking Repository Status | ||
|
||
To check the status of your working directory, incluuding staged, unstaged, and untracked files, run: | ||
```bash | ||
git status | ||
``` | ||
|
||
## 4. Staging Changes | ||
|
||
To stage changes for the next commit, use: | ||
```bash | ||
git add <file-name> | ||
``` | ||
|
||
To stage all changes at once, use: | ||
```bash | ||
git add . | ||
``` | ||
|
||
## 5. Commiting Changes | ||
|
||
To commit your stages changes with a descriptive message, run: | ||
```bash | ||
git commit -m "Your commit message here" | ||
``` | ||
|
||
## 6. Viewing Commit History | ||
|
||
To view the commit history of your repository, use: | ||
```bash | ||
git log | ||
``` | ||
|
||
You can format the output of git log using different tags such as --online for a concise view: | ||
```bash | ||
git log --oneline | ||
``` | ||
|
||
## 7. Pushing Changes | ||
|
||
To push your local commits to a remote repository, use: | ||
```bash | ||
git push origin <branch-name> | ||
``` | ||
|
||
## 8. Pulling Changes | ||
|
||
To update your local repository with changes from the remote repository, run: | ||
```bash | ||
git pull | ||
``` | ||
|
||
## 9. Creating a New Branch | ||
|
||
To create a new branch, use: | ||
```bash | ||
git branch <branch-name> | ||
``` | ||
|
||
## 10. Switching Branches | ||
|
||
To switch to an existing branch, run: | ||
```bash | ||
git checkout <branch-name> | ||
``` | ||
|
||
You can also create and switch to a new branch in one command using this: | ||
```bash | ||
git checkout -b <branch-name> | ||
``` | ||
|
||
## 11. Merging Branches | ||
|
||
To merge changes from one branch into your current branch, use: | ||
```bash | ||
git merge <branch-name> | ||
``` | ||
|
||
## 12. Deleting Branches | ||
|
||
To delete a local branch that you no longer need, run: | ||
```bash | ||
git branch -d <branch-name> | ||
``` | ||
|
||
## Conclusion | ||
|
||
These are some of the basic commands that form the foundation of using Git. Getting comfortable using these commands will help you manage your projects effectively. In the next sections, we will dive into the SFU OS Dev Club specfic Git guidlines as well as more advanced git workflows. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,81 @@ | ||
--- | ||
sidebar_position: 4 | ||
--- | ||
|
||
# Club-Specific Guidelines | ||
|
||
Welcome to the SFU Open Source Development Club! To ensure smooth collaboration on our projects, we have established the following Git guidelines. Please adhere to these practices when working with Git and GitHub. | ||
|
||
## 1. Repository Structure | ||
|
||
- Each project should have its own repository under the club's GitHub organization. | ||
- Follow a consistent naming convention for repositories, such as `project-name` or `club-name/project-name`. | ||
|
||
|
||
## 2. Branching Strategy | ||
|
||
Ensure a new branch is created for each change such as feature, or bug fix. No changes should be made in the main branch. Instead, create a new branch and create a pull request for any changes you want to merge into the main branch. | ||
|
||
### 2.1 Branch Naming | ||
|
||
- Use descriptive names for branches that reflect the purpose of the branch. | ||
- For bug fixes: `bugfix/<issue-number>/short-description` | ||
- For features: `feature/<issue-number>/<short-description>` | ||
|
||
### 2.2 Default Branch | ||
|
||
- The default branch for all projects should be named `main`. | ||
- All development work should be done on seperate branches, and the main branch should always be stable. | ||
|
||
|
||
## 3. Commit Guidelines | ||
|
||
### 3.1 Commit Messages | ||
|
||
- **Use the imperative mood**: Write commit messages in the imperative form (e.g., "Add feature" instead of "Added feature" or "Adding feature"). This aligns with the convention used in Git, making the history easier to read. | ||
|
||
- **Limit the subject line**: Keep the subject line concise, ideally around 50 characters or fewer. This helps maintain readability in logs and ensures that the main point of the commit is clear at a glance. | ||
|
||
- **Separate subject and body**: If you need to provide additional details, separate the subject line from the body with a blank line. Use the body to explain the *why* behind the change, providing context that may not be obvious from the subject line alone. | ||
|
||
- **Be descriptive**: Write commit messages that clearly describe the changes made. Avoid vague messages like "Fixed things" and instead specify what was fixed and why it was necessary. | ||
|
||
- **Reference issues**: If applicable, reference any related issue numbers in your commit message (e.g., "Fixes #123") to establish a clear connection between the commit and the issue being addressed. | ||
|
||
- **Use the body for details**: Use the body of the commit message to explain the reasoning behind the change, any potential impacts, and any relevant background information that may help others understand the context. | ||
|
||
### 3.2 Small Commits | ||
|
||
- Make small, incremental commits. Each commit should represent a single logical change. | ||
- Avoid committing large changes all at once; this makes it harder to track history and review code. | ||
|
||
|
||
## 4. Pull Requests | ||
|
||
### 4.1 Creating Pull Requests | ||
|
||
- Always create a pull request (PR) for any changes you want to merge into the main branch. | ||
- Provide a clear title and description for the PR, referencing any related issues (e.g., "Fixes #3"). | ||
|
||
### 4.2 Review Process | ||
|
||
- Request reviews from at least one other member before merging your PR. | ||
- Address any comments or suggestions from reviewers before merging. | ||
|
||
### 4.3 Merging Pull Requests | ||
|
||
- Only merge PRs into the main branch if they have been reviewed and approved. | ||
- Use the "Squash and merge" option to keep the commit history clean. | ||
|
||
|
||
## 5. Documentation | ||
|
||
- Update the project documentation as part of your PR if your changes affect usage or setup. | ||
- Use Markdown files for documentation and keep them organized within the repository. | ||
|
||
|
||
## 6. Git Best Practices | ||
|
||
- Regularly pull from the main branch to keep your feature branches up-to-date. | ||
- Resolve merge conflicts promptly and communicate with your team about any significant changes. | ||
- Use tags for marking releases in your projects (e.g., `v1.0.0`). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
--- | ||
sidebar_position: 2 | ||
--- | ||
|
||
# Git Setup and Configuration | ||
|
||
|
||
## Installation | ||
|
||
To start using Git, you'll need to install it on your local machine. Below are the installation instructions for various operating systems. | ||
|
||
### Windows | ||
|
||
1. **Download the Installer**: Visit the [Git for Windows](https://gitforwindows.org/) website and download the latest version of the Git installer. | ||
2. **Run the Installer**: Open the downloaded `.exe` file and follow the installation wizard. You can typically accept the default settings. | ||
3. **Verify Installation**: After installation, open `Git Bash` or the Command Prompt and run the following command to verify Git is installed: | ||
```bash | ||
git --version | ||
``` | ||
|
||
### Mac | ||
1. **Using Homebrew**: If you have Homebrew installed, you can easily install Git with the following command: | ||
```bash | ||
brew install git | ||
``` | ||
2. **Verify Installation**: Open the Terminal and run: | ||
```bash | ||
git --version | ||
``` | ||
|
||
### Linux | ||
|
||
For most Linux distributions, Git can be installed via the package manager. | ||
|
||
- **Debian/Ubuntu**: | ||
```bash | ||
sudo apt update | ||
sudo apt install git | ||
``` | ||
|
||
- **Fedora**: | ||
```bash | ||
sudo dnf install git | ||
``` | ||
|
||
- **Arch Linux**: | ||
```bash | ||
sudo pacman -S git | ||
``` | ||
|
||
- **Other Distributions**: If your Linux distribution is not listed here, a quick Google search of your package manager command for Git should help you install. | ||
|
||
|
||
## Initial Configuration | ||
|
||
Following the installation of Git, it's essential to set up your user information. This information will be included in any operations you make, such as commits and merges. | ||
1. **Set Your Name**: | ||
```bash | ||
git config --global user.name "Your Name" | ||
``` | ||
2. **Set Your Email**: | ||
```bash | ||
git config --global user.email "your.email@example.com" | ||
``` | ||
3. **Verify Configuration**: You can verify your user configuration any time by running: | ||
```bash | ||
git config --list | ||
``` | ||
## Conclusion | ||
With Git installed and configured, you are now ready to start using version control in your projects. In the next sections, we'll explore the fundemental Git commands and workflows that will help you manage your code effectively. |
Oops, something went wrong.