Git

Git is a distributed version control system used to track changes in source code and related assets over time. It allows developers to record checkpoints, inspect history, revert mistakes, and synchronize work across machines or remote services.

This reference documents a minimal, intentional Git workflow oriented toward solo developers and small teams, rather than enterprise-scale collaboration.

Linear Git Workflow

As an independent developer, I use Git in a deliberately constrained way.

For most projects, I treat Git as a linear history of checkpoints on a single branch. I rarely branch, almost never merge, and do not rely on Git for collaborative workflows or code review. Each commit represents forward progress, and major milestones are marked using tags.

This approach differs from enterprise Git usage, but it fits my needs:

I work primarily alone
I prioritize archival integrity and recoverability
I want simple, inspectable history
I avoid unnecessary process overhead

This reference reflects that perspective.

Basic Commands

Init

Creates a new Git repository in the current directory by generating a .git folder that stores all version history and configuration.

git init

After initialization, I typically edit the local .git/config file directly rather than memorizing configuration commands.

Stage Changes (Add)

Stages changes in the working directory for inclusion in the next commit.

git add .

Status

Displays the current repository state, including staged, unstaged, and untracked files.

git status

I check this carefully before every commit, especially when:

Refining .gitignore rules.
Working with large binaries or assets
Restructuring directories

Cleaning a bad commit after the fact is far more painful than catching it here.

Unstage Files (Undo Add)

If you staged files by mistake, you can remove them from the staging area without deleting changes.

Unstage everything:

git restore --staged .

Unstage a specific file:

git restore --staged path/to/file

This is the cleanest modern replacement for older git reset patterns.

Commit

Records the staged changes into Git history.

git commit -m "First commit"

I write commit messages:

Imperatively
Without trailing punctuation
Focused on intent rather than implementation

Remote Synchronization

Push to Remote

Synchronizes local commits with a remote repository (e.g., GitHub or GitLab). This assumes the remote has already been configured in the config.

git push origin main

Origin is the primary remote name I use and main the default branch I use.

Dual Remote Push Strategy

I maintain independent repositories on multiple Git hosting platforms (e.g., GitHub and GitLab). These are not mirrors.

Preserve source history even if one provider becomes unavailable
Avoid a single external authority controlling archive access
Ensure that only my local repository determines what gets pushed

This is an archival strategy, not a collaboration strategy. It is informed by the observation that technology platforms can, over time, become ideologically driven and express that stance through aggressive moderation policies or asymmetrical legal mechanisms. When a single platform holds exclusive custody of a body of work, these dynamics represent a real archival risk. Maintaining independent, redundant repositories is a deliberate way to mitigate that threat and preserve long-term control over the archive.

Local .git/config Example

After initializing a repository, I add multiple pushurl entries to the same remote:

[remote "origin"]
	url = https://github.com/user_id/repo_id.git
	fetch = +refs/heads/*:refs/remotes/origin/*
	pushurl = https://github.com/user_id/repo_id.git
	pushurl = https://gitlab.com/user_id/repo_id.git

Back Up Strategy

Git clouds are not my primary backup system. I treat it as a checkpoint mechanism rather than a long-term storage solution.

I perform periodic full backups separately, especially for large assets. Since source code is lightweight compared to the data it depends on, I prefer to back everything up together in a unified process rather than rely on Git LFS.