GitHub Basics

1. Cloning a Repository

●​ Command: git clone <repository-url>

●​ Explanation: Cloning copies the remote repository to your local machine, allowing you
to work on the code offline. It’s the starting point for most projects, giving you access to
the codebase.
●​ Tip: Cloning also sets up a default remote called origin which points to the repository
URL.

2. Setting Remotes and Upstream

●​ If you clone a branch, the remote will already be setup

●​ This is if you are adding a remote separately
●​ Commands:
○​ To view remotes: git remote -v
○​ To add a new remote: git remote add <name> <url>
 ○​ To set an upstream branch: git branch
--set-upstream-to=<remote>/<branch> <local-branch>
●​ Explanation: Remotes are links to repositories hosted elsewhere, like GitHub. Setting
an upstream branch allows you to track a specific branch on a remote, making it easier
to pull updates.
●​ Example: Set up an upstream branch if you’re working on a fork, so you can fetch
changes from the original repo.

3. Committing Changes

●​ Commands:
○​ Stage files: git add <file>
○​ Commit changes: git commit -m "Your message"
●​ Explanation: Committing saves changes to your local repo. It’s an essential part of
version control, as it records each step in your work, allowing you to track and manage
changes.
●​ Tip: Encourage clear, descriptive commit messages to make it easier to understand the
history of changes.

4. Pushing Changes

●​ Commands:
○​ Push committed changes to the remote repository:

git push

○​ First time push (set upstream for a new branch):

git push --set-upstream origin <branch-name>

●​ Explanation: Pushing sends your committed changes from your local repository to the
remote one (like GitHub or GitLab). This makes your work accessible to collaborators
and keeps the remote repo updated. If you're pushing a new branch for the first time,
 you’ll need to set the upstream link using --set-upstream so Git knows where to
push in the future.
●​ Tip: Always commit before you push! Also, pull first to avoid merge conflicts, especially
when collaborating with others.

Example Flow:

git add index.html

git commit -m "Fix header alignment issue on homepage"

git push

5. Breaking and Switching Branches

●​ Commands:
○​ Create a branch: git checkout -b <branch-name>
○​ Switch branches: git checkout <branch-name>
○​ Delete a branch: git branch -d <branch-name>
●​ Explanation: Branches allow you to work on different features or fixes independently
from the main codebase. Breaking (creating) branches lets you isolate changes, and
switching lets you move between different versions of the code.
●​ Example: Create a branch for a new feature, and switch back to the main branch when
needed.

5. Opening a Pull Request (GitHub Website)

●​ Instructions:
1.​ Go to your forked repo or the original repo if you have push access.
2.​ Make sure your branch is up-to-date with the main branch.
3.​ Click on the "Pull Requests" tab and select "New Pull Request."
4.​ Choose the base (main/dev/etc) branch and compare it with your feature branch.
5.​ Write a descriptive title and comment, then submit the pull request.
●​ Explanation: Pull requests (PRs) allow you to request that your changes be merged into
another branch. They facilitate code reviews and discussions before merging.
 ●​ Tip: Include references to issues or previous discussions, if applicable, to provide
context.

Glossary of Terms

●​ Repository (Repo): A project space that stores code files, tracked history, and
collaboration data.
●​ Remote: An external location where your repository is hosted (usually GitHub). origin
is often the default name for the cloned remote.
●​ Upstream: Refers to the original repository you forked from, or the branch your local
branch tracks.
●​ Commit: A snapshot of changes in your codebase, saved locally.
●​ Branch: A parallel version of your code that allows isolated changes, often used for new
features or bug fixes.
●​ Pull Request (PR): A request to merge changes from one branch to another, typically
involving code review and discussion.
Other Information

Commit Guidelines

Commit Messages

●​ Start with a Verb: Begin each commit message with an action verb that clearly indicates
the action taken. This makes it easier to understand the purpose of the commit at a
glance.
○​ Examples: Fix, Add, Update, Remove, Refactor.
●​ Describe the Change: Write a clear and concise description of what was done. Avoid
vague descriptions; instead, focus on what was changed and why.
○​ Examples: "Fix bugs on the admin dashboard," "Update user authentication
flow," "Add search functionality to the job portal."
●​ Capitalization: Use an uppercase letter for the first letter of the commit message.
●​ Length: Keep the message short but informative. For additional detail, use the extended
description field.

Commit Frequency

●​ Milestones: Commit whenever a task, functionality, or bug fix is completed. This practice
marks key points in the project and documents changes incrementally.
●​ Atomic Commits: Make each commit represent a single logical change, keeping
commits "atomic." This makes tracking changes easier and aids debugging.
●​ Work in Progress (WIP) Commits: For ongoing tasks, consider using WIP commits to
save your progress. Use the --no-verify flag if bypassing pre-commit hooks for
intermediate states is needed.
Pull Request (PR) Guidelines

When to Open a PR

●​ Significant Section Completed: Open a PR when a significant section of work is

finished. This enables easier code review and smoother integration into the main
codebase.
●​ Scope: Aim for PRs with about 5-6 file changes and less than 1000 lines of code to help
reviewers provide detailed feedback without being overwhelmed.

PR Titles and Descriptions

●​ Meaningful Titles: Summarize the changes in the title. Avoid generic titles like "Fix
issue" or "Update code."
○​ Examples: "Add pagination to job listings," "Fix memory leak in user session
management."
●​ Detailed Descriptions: In the PR description, list the work done as bullet points and add
relevant context or background information to help reviewers understand the changes.
○​ Example:
■​ Implemented pagination for job listings
■​ Added unit tests for pagination functionality
■​ Updated UI to support pagination controls

Linking Issues

●​ Relevant Issues: Link all relevant GitHub issues after opening a PR. This helps track
progress and aligns the work with broader project goals.
●​ Keywords: Use keywords like Closes #issue_number or Fixes #issue_number
to automatically close the issue when the PR is merged.
Working with GitHub Issues

Assignment

●​ Self-Assignment: Ensure you’re assigned to an issue before starting work. If you’re not
assigned, request assignment from the project manager or team lead to avoid duplicate
efforts.
●​ Collaboration: For issues requiring multiple contributors, ensure all involved team
members are assigned, and communicate regularly to coordinate efforts.

Issue Status

●​ Working on It: Update the issue status to “Working on” when you begin. This signals to
the team that the issue is actively being addressed.
●​ Pending Review: Once your work is ready for a PR, change the status to “Pending
Review.” This indicates that the issue is awaiting code review and testing.

Connecting to GitHub with SSH

SSH keys let you securely connect to GitHub without having to enter your username and
password every time. It's a one-time setup that makes pushing and pulling code faster and
safer.

Visit the link below for the instructions on how to set up

https://docs.github.com/en/authentication/connecting-to-github-with-ssh

Mainly refer to the points below for the set up instructions

Generating a new SSH key and adding it to the ssh-agent
Adding a new SSH key to your GitHub account