4.2. Git Basics

1) Understanding the Basics of Git Setup

Before diving into the operations, it's essential to understand the foundational concepts of Git and GitHub:

• Local vs. Remote: Your local repository is the one on your computer. The remote repository is hosted on GitHub's servers. This distinction is crucial for operations like push, pull, and clone.

• Files and Changes: In Git, you first add files or changes to what's called the "staging area." Once you're satisfied with the changes you've staged, you commit them, which takes a snapshot of the current state of your repository.

• Branches: Think of a branch as a parallel universe. Changes you make in one branch don't affect other branches until you decide to merge them. The main branch (often called "master" or "main") is the primary branch where the definitive version of your project resides.

• Remote Repositories and Naming: When you use GitHub, you'll have a remote version of your repository. By default, this remote is named "origin." It's just a shorthand name for the URL of the remote repository. Similarly, "master" or "main" is the default name for the primary branch.

2)GitHub Basic Operations

a)Basic Behavior

1. Clone

• What it does: Copies a repository to your local machine.
• Why it's used: To get a local copy of a project to start working on it.
• Example:

  git clone [repository_url]

• Parameters:
  • [repository_url]: The URL of the repository you want to clone.

2. Add

• What it does: Adds changes in the working directory to the staging area.
• Why it's used: To stage changes for the next commit.
• Example:

  git add .

• Parameters:
  • .: Adds all changes in the current directory and subdirectories.

3. Commit

• What it does: Saves the staged changes along with a brief log message.
• Example:

  git commit -m "Fixed login bug"

• Parameters:
  • -m: Stands for "message". It's followed by a brief description of the changes.

4. Pull

• What it does: Fetches the latest changes from a remote repository and merges them into your local repository.
• Example:

  git pull origin master

• Parameters:
  • origin: Refers to the remote repository.
  • master: The branch name from which you want to pull changes.

5. Push

• What it does: Sends your local repository changes to a remote repository.
• Example:

  git push origin master

• Parameters:
  • origin: Refers to the remote repository.
  • master: The branch you're pushing to on the remote repository.

b) Management

1. Status

• What it does: Shows which files have changes that are staged or not staged for a commit.
• Example:

  git status

2. Log

• What it does: Shows a log of all the commits made in the repository.
• Example:

  git log

3. Diff

• What it does: Shows the changes between commits, commit and working tree, etc.
• Example:

  git diff

4. Revert

• What it does: Creates a new commit that undoes changes made in a specific commit.
• Example:

  git revert [commit_hash]

• Parameters:
  • [commit_hash]: The unique identifier of the commit you want to revert.

c) Branch Management

1. Branch

• What it does: Creates, lists, or deletes branches.
• Example:

  git branch new-feature

2. Tag

• What it does: Marks specific points in history as being important.
• Example:

  git tag v1.0

3. Checkout

• What it does: Switches between branches or restores working tree files.
• Example:

  git checkout new-feature

• Parameters:
  • new-feature: The name of the branch you want to switch to.

4. Rebase

• What it does: Takes the changes from one branch and "replays" them onto another.
• Why it's used: To maintain a linear commit history.
• Example:

  git rebase master

• Parameters:
  • master: The branch onto which you want to apply the changes from the current branch.

5. Merge

• What it does: Combines the changes from one branch into another.
• Why it's used: To integrate changes from different branches.
• Example:

  git merge feature-branch

• Parameters:
  • feature-branch: The branch whose changes you want to integrate into the current branch.

3) The Value of GitHub in Collaborative Settings

Issues

Issues in GitHub serve as a discussion board for any project-related topic. They can be bugs, feature requests, questions, or general feedback. Each issue can be labeled, assigned to someone, and even linked to a pull request or other issues.

Working on the Same Code

With GitHub, multiple developers can work on the same project simultaneously. They can:

• Fork a repository, which creates a personal copy of the entire project. They can make changes in their fork and then propose these changes to the original project using a pull request.
• Clone a repository, which creates a local copy on their computer. They can then push their changes to branches and create pull requests.

Pull Requests (PRs)

PRs are central to collaboration on GitHub. When you open a PR:

• You're proposing your changes and requesting that someone review and pull in your contribution.
• PRs show diffs, or differences, of the content from both branches. Changes, additions, and subtractions are shown in green and red.
• Once someone reviews and approves the PR, it can be merged into the main branch.

Code Reviews

Before merging a PR, it's common practice to do a code review. This ensures that the code maintains a certain quality and follows the project's guidelines. On GitHub, you can comment on any line in a PR, making collaboration and review straightforward.

Collaborators and Permissions

In a GitHub repository, you can add collaborators, giving them permissions to push directly to the repository. This is useful for trusted team members. For larger projects, it's common to restrict direct pushes and require changes to come through PRs.

GitHub Actions

GitHub Actions is a CI/CD (Continuous Integration/Continuous Deployment) tool integrated into GitHub. It allows you to automate tasks like testing your code whenever someone creates a PR or pushes to a branch.