The Art of Organizing Your Data: Version Control Explained#

Installing Git#

Git is open-source and can be installed on all major operating systems. You can:

• Download the installer for your platform from the official Git website (https://git-scm.com/).
• Use a package manager (e.g., Homebrew on macOS, apt-get on Ubuntu) to install Git.

On macOS, for example, you might use:

1
brew install git

On Ubuntu or Debian-based Linux systems, you might use:

1
sudo apt-get update
2
sudo apt-get install git

On Windows, simply run the .exe you download from Git’s official website.

Creating Your First Repository#

Let’s assume you’ve installed Git. Here’s how to create a new repository:

1. Create a new directory (folder) on your computer or navigate to an existing project folder.
2. Open your terminal or command prompt and navigate to that folder.
3. Initialize the folder as a Git repository:

   1
   git init
   

Git will create a hidden folder .git/ which stores the detailed version history and configuration for your project.

Understanding the Three Git States#

Git has three main states that your files can reside in:

1. Modified: You’ve changed the file, but haven’t committed it yet.
2. Staged: You have marked a modified file in its current version to be part of the next commit.
3. Committed: The data is safely stored in the local database (the repository).

Basic Git Commands#

Below is a table listing some basic commands you’ll use frequently:

A common workflow:

1. Modify some files.
2. git add . to stage changes for commit.
3. git commit -m "Add new feature" to commit changes.
4. Verify git log to see the latest commits.

What Is a Branch?#

A branch is simply a pointer to a particular commit in the repository. By default, Git uses a branch called main (or master in older versions). However, it’s standard practice to create separate branches for new features, bug fixes, or experiments. This way, you can work on changes independently without disturbing the stable branch.

Creating a new branch in Git is simple:

1
git branch feature/new-login

Then you switch to it:

1
git checkout feature/new-login

Or use a shorthand single command:

1
git checkout -b feature/new-login

Merging Your Work#

Once you’re done working on a feature in your branch, you’ll likely merge it back into your main branch. You can:

1. Check out the main branch:

   1
   git checkout main
   

2. Use the merge command:

   1
   git merge feature/new-login
   

3. Resolve any merge conflicts if they occur (we’ll discuss this in detail soon).

Git Stash#

When you’re in the middle of making changes but want to switch branches or pop back to a clean working state, you can use git stash. This command takes your modified, staged changes and puts them on a stack of unfinished changes, leaving your working directory clean. For example:

1
git stash save "WIP: partial updates"
2
git checkout main

When you want to continue your work, you can reapply your stashed changes:

1
git stash list
2
git stash apply stash@{0}

Setting Up a Remote Repository#

A remote repository is typically hosted on a platform like GitHub, GitLab, or Bitbucket. Collaborating with others on these platforms involves pushing local commits to the remote repository and pulling other peoples’ changes down to your local environment.

To associate your local repository with a remote repository, run:

1
git remote add origin https://github.com/username/new-project.git

Pushing and Pulling#

• Push: Sends your local commits to the remote repository.

  1
  git push origin main
  

• Pull: Fetches and merges the remote commits to your local main branch.

  1
  git pull origin main
  

Collaboration Workflows#

Common workflows include:

• Centralized Workflow: Everyone works on the same branch and commits directly.
• Feature Branch Workflow: Each feature or bug fix is developed in its own branch, then merged into the main branch via a merge or pull request.
• Fork and Pull: Common in open-source projects. Each contributor forks (copies) the repository, makes changes, and submits a pull request back to the original repository.

How Merge Conflicts Occur#

Merge conflicts happen when two or more people change the same lines of a file or make deletions/additions that intersect. Git will flag these conflicting segments, marking them in the file like this:

1
<<<<<<< HEAD
2
your changes
3
=======
4
their changes
5
>>>>>>> feature/another-branch

Manual Conflict Resolution#

To resolve:

1. Edit the file to choose which changes (or combination of changes) you want to keep.
2. Remove the conflict markers (<<<<<<<, =======, >>>>>>>).
3. Mark the conflict as resolved by staging and committing:

   1
   git add path/to/file
   2
   git commit -m "Resolve merge conflict"
   

Rewriting History with Git Rebase#

Git rebase is often used to maintain a linear history:

1. Switch to the branch you want to rebase, e.g., feature/new-login.
2. Run:

   1
   git checkout feature/new-login
   2
   git rebase main
   

   This moves the branch’s commits “on top” of the main branch.

You can also perform interactive rebases to squash commits, edit older commit messages, or reorder commits:

1
git rebase -i main

You’ll see an editor with lines for each commit, where you can:

• pick: Keep the commit as is.
• squash: Combine it with the previous commit.
• reword: Change the commit message.
• edit: Pause rebasing to modify the commit.

Git Tags#

Tags are references to specific commits, often used for marking release versions:

1
git tag v1.0
2
git push origin --tags

This helps you and your team identify stable milestones in the project.

Submodules#

Submodules allow you to embed a Git repository as a subdirectory in another Git repository. This is useful for managing dependencies that are also Git repos. For instance, if you have a main project that relies on a separate library in development, you can include it as a submodule:

1
git submodule add https://github.com/username/library.git lib

Then, whenever the library is updated, you can track specific commits or branches of that submodule.

Git Hooks#

Git hooks are scripts that run automatically at certain points in Git’s workflow. Common hooks include:

• pre-commit: Runs before a commit is created (often used for linting).
• post-commit: Runs after a commit (for automated scripts like notifications).
• pre-push: Runs before you push your commits to a remote repository.

Setting up hooks allows you to automate tasks, enforce code quality standards, and maintain consistently formatted commits.

Git Flow#

Git Flow is a branching model popularized by Vincent Driessen. It defines:

1. A main branch that stores the official release history.
2. A develop branch for integration of features.
3. Feature branches from develop.
4. Release branches to prepare for new product versions.
5. Hotfix branches for urgent fixes on the main branch.

This structure can be somewhat heavy for small teams but is excellent for well-established release cycles and continuous project growth.

Trunk-Based Development#

Trunk-Based Development is a more streamlined approach:

1. All developers commit directly (or through short-lived feature branches) to a single branch (the trunk).
2. Frequent merges help avoid large and complex merges later.
3. It often pairs well with continuous integration, ensuring the trunk remains stable.

What Is CI?#

Continuous Integration is a process where every change to a project triggers an automated build and testing workflow. It ensures that any new commit integrates smoothly with the rest of the codebase. Git pairs naturally with CI—each time you push to a remote, your CI server or service (e.g., GitHub Actions, GitLab CI, Jenkins) can run tests automatically.

Setting Up a Basic CI Pipeline#

Suppose you have a Node.js application and you use GitHub. A simple GitHub Actions workflow file, .github/workflows/ci.yml, might look like this:

1
name: CI
2

3
on:
4
  push:
5
    branches: [ main ]
6
  pull_request:
7
    branches: [ main ]
8

9
jobs:
10
  build-test:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - uses: actions/checkout@v2
14
      - name: Use Node.js
15
        uses: actions/setup-node@v2
16
        with:
17
          node-version: '14'
18
      - name: Install dependencies
19
        run: npm install
20
      - name: Run tests
21
        run: npm test

With this file in your repository:

1. Every push or pull request on the main branch triggers a build.
2. The steps install your project’s dependencies and run any tests that you have written.
3. The pipeline will report the result (pass or fail) right in your GitHub pull request or commit history.

Continuous Integration helps detect issues early, improves code quality, and fosters collaboration by providing immediate feedback on each commit.