If you need help installing, Git Across Different Operating Systems is a useful reminder.

We Recommend some VS Code Extnesions for Git.

Authenticating with GitHub is an important step.

Creating A Pull Request will help you prepare your first PR.

Visit the Git Cheatsheet for a quick reference.

Ready to get hands-on? Jump directly to the Practical Exercise: Your First Contribution!

• Repository (Repo): Where your project and its history are stored.
• Commit: A saved snapshot of your changes.
• Branch: A separate line of development within a project.
• Merge: Combining changes from different branches.
• Remote: A connection to a repository hosted elsewhere (like on GitHub).

1. Fork: Make a personal copy of a project on GitHub.
2. Clone: Download your forked project to your computer.
3. Branch: Create a new branch for your changes (e.g., a new feature or bug fix).
4. Push: Upload your changes from your computer to your fork on GitHub.
5. Pull Request (PR): Propose your changes to the original project.

It shows you can use Git and GitHub and is your first step into open source.

• Working directory vs. staging area: Your current files vs. files ready to be saved.
• Commits: Snapshots of your project at a specific time.
• Branches: Parallel lines of work within your project.
• HEAD: What Git considers your current position.
• Local & remote repos: Your computer's copy vs. a copy on a server (like GitHub).

Git needs your name and email to correctly attribute your work. These settings apply globally to all your Git projects.

Open your terminal and run:
git config --global user.name "Your Name"

Double-check that your Git identity was saved correctly:
git config --global --list

VS Code has excellent built-in features to simplify how you connect and authenticate with GitHub:

• Easy Login: Automatically prompts for GitHub login on your first push, especially with HTTPS.
• Secure Credential Storage: Safely remembers your login details (using your OS keychain or similar), so you don't have to re-enter them.
• Automatic Token Refresh: Handles refreshing access tokens in the background, ensuring continuous access.
• Multiple Account Support: Lets you manage and switch between different GitHub accounts for various projects.

Visual Studio Code offers powerful built-in Git integration and is further enhanced by extensions like GitLens. Here are some key features:

• Source Control Tab (Ctrl+Shift+G): Your main hub for viewing changes, staging files, committing, and managing branches.
• Status Indicators in File Explorer: Easily see which files are modified, added, or untracked with visual cues next to filenames.
• Built-in Diff Viewer: Visually compare versions of your files to see exactly what has changed.
• Inline Blame Annotations (with GitLens): See who last modified a line of code and when, directly in the editor (GitLens extension feature).
• Commit Staging with Checkboxes: Simply check boxes to select which changes or parts of files you want to include in your next commit.
• Branch Switching from Status Bar: Quickly view your current branch and switch to others directly from the bottom status bar.
• Conflict Resolution Helpers: Provides visual tools to help you resolve merge conflicts when they occur.
• Integrated Terminal Access: Open a terminal within VS Code to use Git command-line for any advanced operations.

You have two main ways to interact with Git:

1. Terminal / Command Line (CLI):

• Universally Available: Works on all major operating systems (Windows, macOS, Linux).
• Consistent Commands: The Git commands you learn are the same everywhere.
• Full Power & Control: Provides access to all of Git's features and is great for scripting complex workflows.
• Often Preferred by Pros: Many experienced developers favor the CLI for its speed, precision, and efficiency.

2. Graphical User Interface (GUI) Clients:
(Examples: GitHub Desktop, Sourcetree, GitKraken, VS Code's integrated Git panel)

• Visual Interaction: Offers a graphical way to see your repository's history, branches, and changes.
• Potentially Easier for Beginners: The visual nature can make initial Git concepts less intimidating for some.
• Varying Feature Access: While user-friendly, some GUIs might not expose all of Git's advanced commands or options directly.
• Behind the Scenes: GUI tools are essentially user-friendly interfaces that execute standard Git commands for you.

GitLens is widely recognized as one of the most powerful and comprehensive Git extensions for Visual Studio Code. It dramatically enhances your ability to visualize, understand, and navigate your project's Git history.

Key Features Include:

• Line-by-line Blame Annotations: Instantly see who wrote or last changed any line of code and when, right in the editor.
• Commit Search & Exploration: Easily search, filter, and explore the commit history in various insightful ways.
• File and Line History: View the detailed evolution of any file or even specific lines of code over time.
• Branch Comparison Tools: Visually compare branches to understand differences and track changes effectively.
• Revision Navigation: Effortlessly jump between different versions (commits) of your files.
• Interactive Rebase Editor: Provides a powerful UI for more advanced operations like reordering, squashing, or editing commits (use with understanding, as it rewrites history!).

Why It's So Useful:
GitLens makes your Git repository's history and authorship incredibly transparent and accessible, all without leaving your code editor. This significantly boosts productivity and deepens your understanding of how your project has evolved.

Another invaluable VS Code extension for Git users is Git Graph. This tool excels at providing a clear, visual representation of your repository's commit history, branches, and merges.

Key Features & Benefits:

• Graphical Git Log: Transforms the often complex Git log into an easy-to-understand, interactive graph.
• Clear Branch Visualization: Instantly see how branches diverge, where they merge, and the overall structure of your development lines.
• Tag Display: Clearly indicates where tags are placed within your commit history.
• Enhanced Understanding: Makes it much simpler to grasp the flow of changes and the relationship between different commits, especially in projects with multiple contributors or complex branching strategies.
• Repository Overview: Provides a great bird's-eye view of your project's evolution.
• Contextual Git Actions: (For more advanced users) Allows performing some common Git actions directly from the graph.

Why It's a Great Addition:
Git Graph is particularly helpful for beginners and visual learners as it makes the abstract concepts of branches and merges much more tangible. It complements tools like GitLens by focusing on the graphical layout of your Git history.

Here are three primary ways to authenticate your Git operations with GitHub:

Option 1: HTTPS with a Personal Access Token (PAT)

This method uses the familiar HTTPS URLs for your repositories but replaces your account password with a more secure Personal Access Token (PAT). PATs are revocable, can have specific scopes (permissions), and are the recommended way to authenticate for Git over HTTPS.

• How to Get and Use a PAT:

  1. Generate on GitHub: Navigate to your GitHub settings:
     • Click your profile picture (top-right) → Settings.
     • In the left sidebar, scroll down to Developer settings.
     • Go to Personal access tokens → Tokens (classic) or Fine-grained tokens.
     • Click "Generate new token".
     • Give it a descriptive name, set an expiration, and select the necessary scopes (e.g., repo for full control of private repositories).
  2. Copy Your Token: After creating the token, copy it immediately. GitHub will not show it to you again for security reasons. Store it securely (like in a password manager).
  3. Use When Prompted: When Git (over HTTPS) asks for your username and password:
     • Enter your GitHub username.
     • For the password, paste your Personal Access Token.

• Optional: Caching Your PAT (Credential Helper)
  To avoid entering your PAT every time, Git can cache it.
  On your command line, you can tell Git to store credentials:
  git config --global credential.helper store

First, navigate in your terminal to the directory on your computer where you want to store your project. Then, use one of the following git clone commands. Your choice depends on whether you've set up GitHub authentication via HTTPS (with a Personal Access Token - PAT) or SSH keys.

A. Using HTTPS (if authenticating with a PAT):
Remember to replace YOUR_USERNAME with your actual GitHub username.
`git clone https://github.com/YOUR_USERNAME/EduLite.git`

B. Using SSH (Recommended, if you've set up SSH keys):
Replace YOUR_USERNAME with your GitHub username.
`git clone [email protected]:YOUR_USERNAME/EduLite.git`

After cloning your fork, it's a crucial best practice to add a remote connection to the original project repository. This remote is conventionally named upstream.

1. Navigate into Your Cloned Project Directory:
   If you're not already there, change into the directory Git just created:
   (Replace EduLite if your project folder has a different name)
   `cd EduLite`

2. Add the upstream Remote:
   You'll need the URL of the original project you forked from. For the EduLite example, the original is https://github.com/ibrahim-sisar/EduLite.git.

   • Using HTTPS for the upstream remote:
     (Replace with the HTTPS URL of the original project if different)
     `git remote add upstream https://github.com/ibrahim-sisar/EduLite.git`

   • Using SSH for the upstream remote (if you prefer SSH for all remotes):
     (Replace with the SSH URL of the original project if different)
     `git remote add upstream [email protected]:ibrahim-sisar/EduLite.git`

3. Verify Your Remotes (Optional but Recommended):
   You can check that both origin (your fork) and upstream (the original project) are set up correctly:
   `git remote -v`
   You should see output similar to this:
   origin [email protected]:YOUR_USERNAME/EduLite.git (fetch)
origin [email protected]:YOUR_USERNAME/EduLite.git (push)
upstream [https://github.com/ibrahim-sisar/EduLite.git](https://github.com/ibrahim-sisar/EduLite.git) (fetch)
upstream [https://github.com/ibrahim-sisar/EduLite.git](https://github.com/ibrahim-sisar/EduLite.git) (push)
   (The URLs will reflect whether you used HTTPS or SSH for each.)

Why Are Branches So Important?

• Isolation of Work: Keep new, potentially unstable code separate from your stable main branch until it's ready.
• Parallel Development: Allow multiple developers (or even just you working on multiple tasks) to work on different features or fixes simultaneously without tripping over each other.
• Safe Experimentation: Try out new ideas or approaches on a branch. If it doesn't work out, you can simply discard the branch without impacting the main project.
• Clearer History: When branches are merged, they can provide a clear history of how features were developed and integrated.

Here’s the typical process:

1. Edit Existing Files or Create New Ones:

   • Open your project in your preferred code editor (like VS Code).
   • Make the necessary modifications to existing files.
   • Create any new files that your feature or fix requires.
   • This is where you write your code, update documentation, fix that typo, etc.

2. Check the Status of Your Changes (git status):
   After you've made some edits, git status is your best friend. It tells you what Git has noticed about your files.
   `git status`
   The output will show you:

   • "Changes not staged for commit": Lists files that Git knows about (tracked files) that you have modified since your last commit.
   • "Untracked files": Lists new files you've created that Git doesn't yet track.
   • (Later, it will also show "Changes to be committed" for files you've staged.)

3. Review Your Specific Changes (git diff):
   To see the exact line-by-line modifications you've made to your tracked files (those that are not yet staged for commit), use git diff:
   `git diff`

   • This command shows the differences between what's in your working directory and what's in your last commit (or what's in the staging area if you've staged some files already).
   • Lines starting with - (often in red) are lines removed or the old version of changed lines.
   • Lines starting with + (often in green) are lines added or the new version of changed lines.
   • To see changes only for a specific file:
     `git diff path/to/your/file.py`

4. Review Staged Changes (What Will Be in Your Next Commit):
   After you "stage" your changes (which we'll cover in the very next section!), you can see a diff of exactly what will go into your next commit using:
   `git diff --staged`
   (An older, equivalent command is `git diff --cached`.)
   This is like a final review of your "package" of changes before you formally save it with a commit message.

The command to move changes from your working directory to the staging area is git add.

Common Ways to Use git add:

• Stage All Changes in a Specific File:
  If you want to include all modifications in one particular file:
  `git add path/to/your/filename.js`
  (Replace path/to/your/filename.js with the actual file path.)

• Stage All Changes in a Specific Directory:
  To add all modified and new (untracked) files within a particular directory and its subdirectories:
  `git add path/to/your/directory/`

• Stage All Changes in the Current Directory (and subdirectories):
  This is a very common and powerful command. The . symbol refers to your current working directory.
  `git add .`
  This command stages all modified files and all new untracked files from the current directory downwards.

Verifying What You've Staged:

It's essential to check what you've staged before you commit.

1. Using git status:
   Run `git status` again after using git add. You'll see:

   • Files listed under "Changes to be committed": These are now in the staging area.
   • Any other modified files (that you didn't add) will remain under "Changes not staged for commit."
   • Untracked files that were not added will still be listed as untracked.

2. Using git diff --staged (Review Actual Content):
   To see the exact line-by-line changes that are currently in your staging area (i.e., what will be included in your next commit), use:
   `git diff --staged`
   (You might also see its older synonym, `git diff --cached`.)
   Reviewing this output is a great final check before you write your commit message.

The command to create a commit is git commit. It takes the files currently in your staging area and records them as a new version in your local repository.

Ways to Commit:

• For a Short, Single-Line Message (Most Common for Simple Changes):
  Use the -m flag followed by your commit message in quotes:
  `git commit -m "Add validation for user login form"`
  This command creates the commit immediately with the message you provided.

• For Longer, Multi-Line Messages (Recommended for More Significant Changes):
  If your changes require more explanation than a single line, simply run:
  `git commit`
  This will open your system's default text editor (or the one Git is configured to use, like VS Code, Vim, Nano). In the editor:

  1. Write a concise subject line (ideally 50 characters or less).
  2. Leave a blank line after the subject.
  3. Write a more detailed body explaining the "what" and "why" of your changes, if necessary. You can use multiple paragraphs.
     Once you save and close the editor, Git will create the commit with your full message.

Writing Effective Commit Messages:

A well-written commit message is crucial. It helps others (and your future self!) understand the purpose of the change without having to read all the code.

• Start with an Imperative Verb (Command Tense):
  Treat the subject line as if you're giving an order to the codebase.

  • Examples: `Add user profile page`, `Fix typo in README`, `Update API documentation`, `Refactor login logic`, `Remove deprecated feature`.
  • Avoid: "Added...", "Fixing...", "Updates..."

• Keep the Subject Line Concise:
  Aim for around 50 characters (max ~72) for the subject. This ensures it displays well in various Git tools (like git log --oneline).

• Explain "What" and "Why," Not "How":

  • Your code shows how the change was made.
  • Your commit message should explain what the change does and why it was necessary or beneficial.
  • Example: Instead of "Changed loop variable name," a better message might be "Refactor: Clarify variable name in user processing loop for readability."

• Use the Body for Details:
  If the "what" and "why" need more than a short subject line, use the body of the commit message (when you run git commit without -m).

• Maintain Consistency:
  If you're contributing to an existing project (like EduLite), look at its commit history (git log) to see the style and conventions used, and try to follow them.

The command to send your local committed changes to a remote repository is git push. In most common workflows for contributing, you'll be pushing to origin, which is the conventional name for the remote that points to your fork on GitHub.

Pushing a New Branch for the First Time

If you've created a new branch locally (e.g., feature/amazing-new-thing) and made commits on it, the very first time you push this branch to your origin (your fork), you need to tell Git to establish a link between your local branch and the new branch on the remote.

• The Command:
  `git push -u origin your-branch-name`
  (Make sure to replace your-branch-name with the actual name of your local branch, like feature/amazing-new-thing.)

• Breaking Down the Command:

  • git push: The core command to send changes.
  • -u (or its longer, more descriptive form --set-upstream): This flag is very important for the first push of a branch. It does two key things:
    1. It pushes your local your-branch-name to the origin remote, creating a branch with the same name there if it doesn't already exist.
    2. It sets up a "tracking relationship." This means your local branch will now "track" (or be linked to) the remote branch origin/your-branch-name. This simplifies future pushes and pulls from this branch.
  • origin: The name of your remote repository (which, by default, is your fork on GitHub).
  • your-branch-name: The name of your local branch that you want to push.

  After this command successfully completes, your branch and all its commits will be on your GitHub fork.

Pushing Subsequent Commits to an Existing Remote Branch

Once your local branch is tracking a remote branch (because you used the -u flag on its first push), sending any new local commits you make on that branch is much simpler:

• The Command:
  `git push`

• Why This Works:
  Since the tracking relationship was established, Git knows that when you're on your-branch-name locally and type git push, you intend to send the commits to origin/your-branch-name. No need to specify the remote or branch name again!

Before you begin, quickly double-check that you have:
1. Committed all your desired changes to your local feature branch.
2. Pushed that feature branch from your local machine to your remote fork on GitHub.

Now, let's create the PR using the GitHub website:

1. Navigate to the Original Project Repository:
   Go to the main page of the repository you forked from (e.g., for our example, this would be ibrahim-sisar/EduLite on GitHub).

2. Start a New Pull Request:

   • Option A (Often Automatic): If you've recently pushed a new branch to your fork, GitHub is usually smart enough to detect this. You'll often see a yellow banner or a prominent button on the original repository's page saying something like Compare & pull request next to your branch name. If you see this for your feature branch, click it! This is the quickest way.
   • Option B (Manual): If you don't see the automatic prompt, click on the Pull requests tab (usually located near the top of the repository page, alongside "Code", "Issues", etc.). On the Pull Requests page, click the green New pull request button.

3. Configure the Base and Head Branches (This is Crucial!):
   You'll be taken to a "Comparing changes" page. This is where you tell GitHub what you want to merge and where you want to merge it.

   • Base Repository & Base Branch:
     • Ensure the "base repository" is the original project (e.g., ibrahim-sisar/EduLite).
     • The "base" branch (dropdown) should be the branch in the original project that you want your changes to be merged into. This is typically main, master, or sometimes a develop branch. (Check the project's CONTRIBUTING.md if unsure).
   • Head Repository & Compare Branch:
     • You will likely need to click the link that says compare across forks. This allows you to select your fork.
     • Set the "head repository" to your fork (e.g., YOUR_USERNAME/EduLite).
     • Set the "compare" branch (dropdown) to your feature branch from your fork (the one containing the changes you just pushed).

   Once these are correctly set, GitHub will show you a summary of your commits and a "diff" (the changes you've made).

4. Review Your Changes:
   Take a moment to look at the diff displayed. Does it include all the changes you intended and nothing extra? This is a good final check.

5. Create the Pull Request & Write a Clear Description:

   • If everything looks good, click the green Create pull request button.
   • You'll now see a form where you provide a Title and a Description for your PR:
     • Title: Make it clear and concise, summarizing your changes (e.g., "Fix: Prevent crash on invalid user input" or "Feat: Add dark mode toggle to settings").
     • Description (Body): This is very important!
       • Clearly explain what changes your PR introduces.
       • Explain why these changes were made (e.g., what bug it fixes, what feature it adds).
       • If your PR addresses a specific GitHub Issue, link to it by typing its number (e.g., Closes #42, Fixes #123). This often automatically links the PR and the issue.
       • Include screenshots or GIFs for any UI changes.
       • If there are specific testing steps, mention them.
       • (Many projects have a Pull Request template that will guide you on what information to include.)

6. Submit Your Pull Request:
   After filling out the title and description thoroughly, click the final Create pull request button at the bottom of the form.

And that's it! Your Pull Request is now open and visible on the original project's "Pull requests" tab. Maintainers will be notified, any configured automated checks (like tests) will run, and the review process will begin. Be prepared to answer questions or make further changes based on feedback!

Scenario 1: Addressing Review Feedback

If reviewers ask for changes on your PR:

1. Make the Changes Locally:

   • First, make sure you are on your feature branch:
     `git checkout your-feature-branch`
     (Replace your-feature-branch with the actual name of your branch.)
   • Use your code editor to make the requested modifications to your files.

2. Commit Your New Changes:

   • Stage the files you've changed:
     `git add .` (to stage all changes in the current directory)
     or `git add path/to/specific/file.py` (to stage specific files).
   • Commit these changes with a clear message, often referencing the review:
     `git commit -m "Address review feedback: Refactor user service"`
     You can also create multiple small commits if the feedback involves several distinct points.

3. Push to Your Fork:
   Push the new commit(s) to the exact same branch on your remote fork (usually origin):
   `git push`

   GitHub will automatically detect these new commits and add them to your existing Pull Request. There's no need to close and re-open it!

Scenario 2: Updating Your Branch with Changes from the Original Project's Main Branch (Rebasing)

It's good practice to keep your feature branch up-to-date with the latest changes from the original project's main development line (e.g., upstream/main or upstream/develop). This helps prevent large merge conflicts when your PR is eventually merged. Rebasing is a common and clean way to achieve this.

1. Ensure Your Local Knowledge of upstream is Current:
   Fetch the latest changes from the upstream remote (the original project):
   `git fetch upstream`

2. Switch to Your Feature Branch:
   Make sure you are on the branch you want to update:
   `git checkout your-feature-branch`

3. Rebase Your Branch onto upstream/main:
   This command takes the commits from your feature branch and re-applies them, one by one, on top of the latest commit from upstream/main (or whichever branch is the target, like upstream/develop).
   `git rebase upstream/main`

   • Note: Rebasing rewrites the commit history of your local feature branch. The commit SHAs will change.
   • Conflicts: If your changes conflict with changes from upstream/main, Git will pause the rebase and ask you to resolve the conflicts. After resolving them in your editor, you'll use `git add <conflicted-file>` and then `git rebase --continue`. (Detailed conflict resolution is often covered in its own section.) If you get stuck, you can abort with `git rebase --abort`.

4. Push Your Rebased Branch to Your Fork:
   Because rebasing rewrites history, your local branch will have diverged from the version on your remote fork. You'll need to "force push" to update the branch on origin.
   `git push --force origin your-feature-branch`
   (Or, if your local branch is correctly tracking the remote branch and has the same name, often just `git push --force` or `git push -f` will work.)

When a merge conflict happens (for example, during a `git rebase`, `git merge`, or even a `git pull` that involves a merge), Git will:
1. Inform you that there are conflicts.
2. Modify the conflicted files to show you exactly where the overlapping changes are, using special "conflict markers."
3. Pause the ongoing operation (e.g., the rebase or merge) until you've resolved the issues.

Here’s how to approach resolving them:

1. Identify the Conflicted Files

• Git will usually list the files that have conflicts in its output.
• Running `git status` is your best friend here. It will clearly show "Unmerged paths" (or similar), listing the files that need your attention.

2. Understand the Conflict Markers in the File

Open each conflicted file in your code editor. You will see sections clearly marked by Git, like this example:

• <<<<<<< HEAD: Marks the beginning of the conflicting lines from your current changes (what HEAD pointed to).
• =======: This line separates your changes from the "incoming" changes.
• >>>>>>> ...: Marks the end of the conflicting lines from the other source (the branch name or commit reference after >>>>>>> tells you where these changes came from).

3. Resolve the Conflict in Your Editor

Your task is to edit the file to make it look exactly how you want the final, merged version to be.
* Read the conflicting sections carefully.
* Decide what to keep:
* You might want to keep only your version (the lines between <<<<<<< HEAD and =======).
* You might want to keep only their version (the lines between ======= and >>>>>>> ...).
* You might need to combine parts of both versions.
* You might even need to write something entirely new that incorporates both ideas.
* Crucially, you must delete all the conflict marker lines (<<<<<<< ..., =======, >>>>>>> ...) once you've made your edits. The file should only contain the code/text you intend to keep.
* Save the file after you've resolved the conflict within it.

4. Stage the Resolved File(s)

After you've edited a conflicted file and saved your resolution, you need to tell Git that you've handled it by adding it to the staging area:
`git add path/to/your/resolved_file.txt`
If you had multiple conflicted files, you'll need to resolve and `git add` each one.
(You can also use `git add .` if you're sure all resolved files are ready and there are no other unintended changes to stage.)

5. Complete the Interrupted Operation

The command to finalize the process depends on what operation caused the conflict:

• If the conflict occurred during a git merge:
  Once all conflicts are resolved and staged, complete the merge by creating a merge commit:
  `git commit`
  (Git usually provides a default merge commit message, which you can edit.)

• If the conflict occurred during a git rebase (common when updating your PR branch):
  The sequence you provided in your original snippet is for this scenario. Here's the flow:

  1. You likely started with `git fetch upstream` and then `git rebase upstream/main`.
  2. Git paused due to a conflict.
  3. Resolve & Stage: You've just done this (Steps 2, 3, and 4 above).
  4. Continue the Rebase: Tell Git to proceed with applying the rest of your commits:
     `git rebase --continue`
     If more conflicts arise on subsequent commits during the rebase, repeat the resolve-add-continue cycle.
  5. Aborting a Rebase (Escape Hatch): If the rebase becomes too complex or you want to start over, you can abort it:
     `git rebase --abort`
     This will return your branch to the state it was in before you started the rebase.
  6. After a Successful Rebase: Once the rebase completes without further conflicts, your local branch's history has been rewritten. You will then need to force push to update your branch on your remote fork (e.g., origin):
     `git push --force origin your-feature-branch`
     (Or, more safely, `git push --force-with-lease origin your-feature-branch`)

Here are some common Git commands grouped by their general purpose:

• Setting Up Your Environment & Project:

  • `git clone <repository_url>`: Downloads a copy of an existing remote repository (like a fork) to your local machine.
  • `git config --global user.name "Your Name"`: Sets the name that will be attached to your commits globally.
  • `git config --global user.email "[email protected]"`: Sets the email that will be attached to your commits globally.

• Checking Status & Reviewing Changes:

  • `git status`: Shows the current state of your working directory and staging area (what's changed, what's staged, what's untracked).
  • `git log`: Displays the commit history for the current branch. (Use q to quit the log view).
  • `git diff`: Shows the line-by-line differences between your working directory files and your last commit (or staged changes).
  • `git diff --staged` (or `git diff --cached`): Shows the differences between your staged changes and your last commit (i.e., what will be in the next commit).

• Working with Branches:

  • `git branch`: Lists all your local branches. The current branch is marked with an asterisk (*).
  • `git branch <new-branch-name>`: Creates a new local branch (but doesn't switch to it).
  • `git checkout <branch-name>`: Switches your working directory to an existing branch.
  • `git checkout -b <new-branch-name>`: Creates a new local branch and immediately switches to it. This is very common.

• Staging & Committing Changes (The Core Workflow):

  • `git add <file-or-directory-path>`: Adds changes from the specified file(s) or directory to the staging area.
  • `git add .`: Stages all new and modified files in the current directory and its subdirectories. (Use with `git status` first to be sure!)
  • `git commit -m "Your concise commit message"`: Records the staged changes to your local repository with a short message.
  • `git commit`: Opens your text editor to write a more detailed (multi-line) commit message.

• Synchronizing with Remote Repositories (like GitHub):

  • `git remote -v`: Lists all your configured remote repositories (like origin and upstream).
  • `git fetch <remote_name>` (e.g., `git fetch upstream`): Downloads changes, branches, and tags from the specified remote repository but does not merge them into your local working branch.
  • `git pull <remote_name> <branch_name>` (e.g., `git pull origin main`): Fetches changes from the specified remote branch and immediately tries to merge them into your current local branch. (Equivalent to git fetch followed by git merge).
  • `git push -u <remote_name> <branch_name>` (e.g., `git push -u origin feature/my-work`): Pushes your local branch to the remote repository for the first time and sets up upstream tracking.
  • `git push`: Pushes your committed changes from your current local branch to its linked remote branch (if tracking is set up).
  • `git rebase <base_branch>` (e.g., `git rebase upstream/main`): Re-applies commits from your current branch onto the tip of another branch, creating a linear history. Use with caution, especially on shared branches, as it rewrites history.

• Temporarily Saving Changes & Undoing (Use with Care):

  • `git stash`: Temporarily shelves uncommitted changes (both staged and unstaged) in your working directory, allowing you to switch branches or work on something else. Use `git stash pop` or `git stash apply` to reapply.
  • `git reset <file>`: Unstages a file (removes it from the staging area) but keeps the changes in your working directory.
  • `git revert <commit-hash>`: Creates a new commit that undoes the changes introduced by a previous commit. This is a safe way to undo changes in a shared history because it doesn't alter existing history.
  • `git reset --hard <commit-hash-or-HEAD>`: (Potentially Destructive!) Resets your current branch HEAD, staging area, and working directory to a specific commit, discarding all changes made since that commit in the working directory and staging area.

While the CONTRIBUTING.md is your main guide, here are some key ways to get started:

• Setting Up Your Environment:

  • Our CONTRIBUTING.md (along with specific README.md files in the backend and Frontend directories) has detailed instructions for setting up your local development environment.

• Finding Something to Work On:

  • A great place to start is by Browse the EduLite GitHub Issues.
  • Look for issues labeled good first issue or help wanted – these are often well-suited for new contributors.
  • Don't hesitate to comment on an issue to ask clarifying questions or express your interest in working on it.

• Communication & Getting Help:

  • Join our Discord Server: The EduLite Discord is perfect for general chat, asking quick questions, and collaborating with other contributors.
  • Use GitHub Discussions: For broader ideas, more in-depth Q&A, or project-wide topics, head over to our GitHub Discussions.

• Following Project Guidelines:

  • Always adhere to the coding standards and development practices outlined in our CONTRIBUTING.md.
  • Ensure your contributions are well-tested and align with the project's goals.
  • Communicate respectfully and constructively with everyone in the community.

Remember, the CONTRIBUTING.md file is your primary resource for all contribution details!

Here are some highly recommended resources to explore as you continue to develop your Git and GitHub skills:

• Pro Git Book (Free Online):
  Considered by many to be the definitive guide to Git. It's comprehensive, well-written, and available for free online at git-scm.com/book. It covers everything from the basics to advanced internals.

• GitHub Learning Lab:
  Interactive, bot-led courses directly on GitHub that guide you through real-world scenarios and projects. Find it at lab.github.com.

• Official Git Documentation:
  The official documentation at git-scm.com/doc is an excellent reference for every Git command and concept.

• Official GitHub Docs:
  For anything related to GitHub features (Pull Requests, Issues, Actions, etc.), check out docs.github.com.

• Stack Overflow:
  An invaluable resource for troubleshooting specific Git or GitHub problems. Chances are, if you have a question, someone has already asked and answered it there.

• YouTube Tutorials:
  Many creators offer excellent visual tutorials on Git and GitHub, catering to all learning styles. Search for topics like "Git for beginners," "GitHub workflow," or specific commands.

• Interactive Learning (try.github.io):
  GitHub's interactive tutorial site (though some content might be older, the basics are still solid) can be a fun way to get hands-on practice.

• Git Visualization Tools:
  Tools that help you visualize your branches and commit history (like some VS Code extensions or standalone apps) can greatly aid in understanding complex repositories. Search for "Git visualization tools" to find options.