Data Scientist

Data Scientist

he/him

I am a Data Scientist and Researcher. I am Interested in LLMs, Deep Learning, and Computer Vision.

Git and Github

Date:

Git is a distributed version control system (VCS) that helps you track changes to your code, work on features safely, and collaborate with others. GitHub is a cloud platform built on top of Git that hosts your repositories, makes collaboration easier, and adds features like pull requests, issues, and Actions. In this note, we will walk through Git concepts and the most important Git commands you will actually use in day‑to‑day work: creating repositories, cloning, branching, committing, pushing, pulling, merging, and resolving conflicts. We will also see how Git connects to GitHub.

1. Core Concepts in Git

1.1 Repository

A Git repository (often shortened to “repo”) is a folder that Git tracks. It contains:

  • Your project files (code, docs, etc.).
  • A hidden .git directory (all Git history and metadata).

Two major types:

  • Local repository – the copy on your machine.
  • Remote repository – the copy on a server (e.g., GitHub).

1.2 Three Main Areas: Working Directory, Staging Area, Repository

Git’s power comes from how it manages your changes across three areas:

  1. Working directory
    • The actual files and folders you are editing.
  2. Staging area (index)
    • A temporary area where you mark which changes should be part of the next commit.
  3. Repository (history)
    • Where committed snapshots live permanently (until you rewrite history).

Typical flow:

# 1. Edit files in working directory
git status

# 2. Stage changes
git add file1.py file2.py

# 3. Commit staged changes to repository
git commit -m "Meaningful commit message"

1.3 Commit

A commit is a snapshot of your project at a specific point in time, plus metadata (author, timestamp, message, parent commit). Each commit has a unique hash like a1b2c3d. Good commits are small, focused, and have clear messages.

Examples of good commit messages:

  • Add user login validation
  • Fix bug in payment calculation
  • Refactor API client for clarity

1.4 Branch

A branch is a movable pointer to a sequence of commits. Branches allow you to isolate work (features, bug fixes, experiments) without touching the main code line. The default branch is often called main (or master in older repositories).

Common workflow:

  • main – always stable, deployable code.
  • Feature branches – e.g., feature/login, bugfix/payment-crash.

We will look at branch commands later in detail.

1.5 Remote

A remote is a reference to a repository hosted elsewhere (like GitHub). The default remote name is usually origin. You push your local commits to remotes and pull changes from remotes into your local repo.

2. Getting Started with a Repository

2.1 Creating a New Repository from Scratch

# Create a folder
mkdir my-project
cd my-project

# Turn it into a Git repository
git init

This creates a hidden .git folder. Your repository is empty until you add files and commit.

# Create a file
echo "# My Project" > README.md

# See current status
git status

# Stage the file
git add README.md

# Commit the file
git commit -m "Initial commit"

2.2 Cloning an Existing Repository (git clone)

If a repository already exists on GitHub (or any remote), you usually clone it. Cloning creates a full copy of the repo, including its history and branches.

git clone https://github.com/user/repo.git

This will:

  • Create a folder named repo (or a custom name if you add it at the end).
  • Set origin to point to the remote URL.
  • Check out the default branch (usually main).

Example with a custom folder name:

git clone https://github.com/user/repo.git my-local-repo

3. Inspecting the Repository

3.1 Checking Status (git status)

git status

Shows which files have changed, which are staged, and which are untracked (new files). This is your “current situation” dashboard. Use it often.

3.2 Viewing History (git log)

git log

Helpful options:

git log --oneline          # One-line summary of each commit
git log --graph --oneline --all
                           # ASCII graph of branches and merges

4. Staging and Committing

4.1 Adding Files (git add)

git add file1.py
git add dir/               # Add entire folder
git add .                  # Add all changed files

git add does not immediately save your changes in history; it marks them to be included in the next commit.

4.2 Creating Commits (git commit)

git commit -m "Explain what you did"

For more detailed messages:

git commit
# This opens your default editor where you can write a multi-line message.

A healthy habit is to make commits that represent a logical change: one bug fix, one feature, one refactor. Avoid mixing unrelated changes in the same commit.

5. Branching in Depth (git branch, git switch / git checkout)

5.1 Why Use Branches?

Branches let you build new features or experiments without breaking the main code. When the work is done and tested, you merge the branch back into main. If things go wrong, you can abandon the branch without affecting main.

5.2 Creating and Listing Branches

# List all local branches
git branch

# Create a new branch (but stay on current branch)
git branch feature/login

5.3 Switching Branches

Newer Git versions recommend git switch:

# Create and switch
git switch -c feature/login

# Switch to existing branch
git switch main

Older syntax with git checkout:

git checkout -b feature/login   # create + switch
git checkout main               # switch

5.4 Deleting Branches

git branch -d feature/login     # delete local branch (safe if merged)
git branch -D feature/login     # force delete (even if not merged)

6. Working with Remotes & GitHub

6.1 Connecting a Local Repo to GitHub

  1. Create a new empty repository on GitHub (without README if you already have one locally).
  2. Connect your local repo to GitHub:
git remote add origin https://github.com/your-username/your-repo.git
  1. Push your local main branch to GitHub:
git push -u origin main

The -u flag sets origin/main as the upstream for your local main branch, so later you can simply use git push and git pull without specifying branch names.

6.2 Viewing and Renaming Remotes

git remote -v            # List remotes and their URLs

git remote rename origin upstream   # Rename a remote (example)

7. Pulling & Fetching from Remotes (git pull, git fetch)

7.1 Fetch vs Pull

When others push changes to GitHub, you need to bring them into your local repo. There are two main ways to do this: fetch and pull.

  • git fetch – Downloads new commits from the remote but does not modify your working branch. You can inspect changes first.
  • git pull – Equivalent to git fetch + git merge (by default). It updates your current branch with remote changes.

7.2 Fetching

git fetch origin

This updates remote tracking branches like origin/main, but your local main stays unchanged until you merge or rebase.

7.3 Pulling (git pull)

# Pull changes from origin for the current branch
git pull

or explicitly:

git pull origin main

Use git pull before starting new work to make sure your branch is up to date with the remote.

8. Pushing to Remotes (git push)

# Push local main to origin
git push origin main

# After first time with -u, you can often just run:
git push

For new branches:

git push -u origin feature/login

This both creates the branch on GitHub and sets it as the upstream branch so future pushes are simple.

9. Merging Branches (git merge)

9.1 What is a Merge?

A merge combines the history of one branch into another. In a typical feature workflow, you:

  1. Start from main
  2. Create branch feature/xyz
  3. Do work, commit changes on feature/xyz
  4. Merge feature/xyz back into main

9.2 Basic Merge Example

# Start on main
git switch main

# Make sure main is up to date
git pull

# Merge feature branch into main
git merge feature/login

If Git can merge automatically, it creates a new merge commit.

9.3 Fast-Forward vs Merge Commit

  • Fast-forward – When main has not moved since you branched, Git just moves the main pointer forward. No merge commit is created.
  • Merge commit – When both branches have new commits, Git creates a special commit combining both histories.

You can force a merge commit even when fast-forward is possible:

git merge --no-ff feature/login

10. Merge Conflicts

10.1 What is a Merge Conflict?

A merge conflict happens when Git cannot automatically combine changes from two branches. Typically, this occurs when the same lines in the same file were edited differently in each branch.

Example conflict markers inside a file:

<<<<<<< HEAD
Current branch changes
=======
Changes from the branch being merged
>>>>>>> feature/login

10.2 Resolving a Conflict

  1. Open the conflicted file(s).
  2. Manually edit to keep the correct code (sometimes a mix of both versions).
  3. Remove the conflict markers (<<<<<<<, =======, >>>>>>>).
  4. Mark the file as resolved:
git add conflicted_file.py
  1. Complete the merge:
git commit

Or if the conflict came from git pull, the final commit finishes the pull.

If you want to abort the merge:

git merge --abort

11. Rebase (Optional, but Important in Teams)

git rebase rewrites the history of a branch by placing its commits on top of another branch. This can create a cleaner, linear history, but it must be used carefully in shared branches.

11.1 Basic Rebase Example

# Suppose you're on feature/login
git switch feature/login

# Rebase on top of main
git fetch origin
git rebase origin/main

Now it looks as if you started your feature branch from the latest origin/main. After rebasing a branch that others use, you typically need to force push:

git push -f origin feature/login

Use with caution. Many teams only rebase local, unshared branches.

12. Stashing (git stash)

When you have uncommitted changes but need to switch branches quickly (for example, to fix a bug elsewhere), you can use git stash to temporarily store your changes.

git stash              # Save uncommitted changes
git switch other-branch
# ... do work ...
git switch original-branch
git stash pop          # Get changes back and remove from stash

13. Undoing Changes Safely

13.1 Discard Changes in Working Directory

git checkout -- file.txt   # older syntax
git restore file.txt       # newer syntax

13.2 Unstage Files

git reset HEAD file.txt    # Remove from staging, keep changes

13.3 Revert a Commit (Safe for Shared History)

git revert <commit-hash>

This creates a new commit that undoes the changes of a previous commit, without deleting any history. It is safe to use on branches that others are using.

13.4 Reset (Powerful, Use Carefully)

git reset --hard <commit-hash>

Hard reset changes your current branch to the given commit and discards all later commits and working directory changes. This can lose work if used incorrectly, especially on shared branches.

14. GitHub Concepts: Forks, Pull Requests, Issues

14.1 Fork

A fork is your own copy of someone else’s GitHub repository under your account. You usually:

  1. Fork the repo on GitHub.
  2. Clone your fork locally.
  3. Create branches and work on them.
  4. Push branches to your fork.
  5. Open a pull request to the original repository.

14.2 Pull Request (PR)

A pull request is a request to merge one branch into another (often from your feature branch into the main branch of a repository). It is where code reviews, comments, and checks happen.

Typical steps:

  1. Push your feature branch to GitHub:
    git push -u origin feature/login
  2. On GitHub, click “Compare & pull request”.
  3. Describe what you changed and why.
  4. Request reviewers.
  5. Address feedback and push additional commits to the same branch.
  6. When approved, merge the PR (via GitHub) into main.

14.3 Issues

Issues are GitHub’s way of tracking bugs, feature requests, and tasks. You can link commits and pull requests to issues using syntax like Fixes #123 in your commit or PR description.

15. Critical Commands Cheat Sheet

15.1 Repository Basics

git init                      # Initialize a new repo
git clone <url>               # Clone existing repo
git status                    # Check current status
git log                       # View commit history

15.2 Staging & Committing

git add <file>                # Stage file
git add .                     # Stage all changes
git commit -m "message"       # Commit staged changes

15.3 Branching & Merging

git branch                    # List branches
git branch <name>             # Create branch
git switch <name>             # Switch branch (newer)
git checkout <name>           # Switch branch (older)
git merge <branch>            # Merge branch into current

15.4 Remotes & Syncing

git remote -v                 # Show remotes
git remote add origin <url>   # Add remote
git push -u origin main       # Push branch first time
git push                      # Push changes
git fetch                     # Get updates from remote
git pull                      # Fetch + merge into current branch

15.5 Undo & Cleanup

git stash                     # Temporarily save local changes
git stash pop                 # Restore stashed changes

git restore <file>            # Discard local changes to file (newer)
git checkout -- <file>        # Same (older syntax)

git reset HEAD <file>         # Unstage file
git revert <hash>             # Safely undo commit
git reset --hard <hash>       # Dangerous: reset branch to commit

In a real project, a simple and healthy daily Git workflow might look like this:

  1. Update your local main
    git switch main
git pull
  2. Create a feature branch
    git switch -c feature/new-api
  3. Work and commit often
    # edit files
git status
git add .
git commit -m "Implement basic API endpoint"
  4. Push your branch and open a PR
    git push -u origin feature/new-api

  5. Fix any review comments – commit and push again.

  6. Merge the PR once approved, then pull the updated main locally.

With these concepts and commands, you can confidently use Git and GitHub for most day‑to‑day tasks in software development and AI engineering projects. Over time, you will naturally pick up more advanced features like interactive rebasing, submodules, and Git hooks, but this foundation is enough to work effectively on real teams.