EXPLAINER

Git

Git is a distributed version-control system. It records snapshots of a project so you can branch, review, and return to a known state. GitHub is a host for Git repositories, not the tool itself.

Short answer: Git records changes to a project so you can branch and merge. GitHub hosts Git repositories. Commit small, write messages that say why, and do not commit secrets.

What it is

Git is a distributed version-control system. A repository is a folder whose history Git tracks. A commit is a snapshot with a message and a pointer to its parent. A branch is a movable name for a commit, so two lines of work can proceed. Merge joins them. You can work offline because the history is on your machine, then push to a remote that teammates share. GitHub is the most common host. GitLab and others speak the same Git protocol. The host is not Git.

If you only remember one thing: Git is the history of the files. The pull request is a host feature on top.

Why and when it is used

Use Git for any project you might regret losing or need to explain later, including solo work. Branches let a change be reviewed before it lands on the main line. Bisect and history help you find when a bug appeared. CI systems trigger on Git events (CI and CD).

Do not use Git as a backup for large binary assets, model weights, or databases. Those belong in artifact storage. Do not commit secrets. A secret in history is still in history after you delete the file in a later commit.

How it works

Git stores content-addressed objects. A commit points at a tree of files. Changing a file and committing creates a new commit; it does not edit the old one. That is why history rewrite (rebase, force-push) is a team decision: you are replacing commits other people may have. git status shows what is staged. The index (staging area) lets you commit part of your work. diff shows the change. Remotes are named URLs. push and pull synchronise. A merge commit joins two parents. A fast-forward just moves the branch pointer.

Conflicts happen when two commits edit the same lines. Git marks them. You edit the file to the result you actually want and commit. The conflict is not an error in Git. It is two truths that need a decision.

Technologies and dependencies

The Git CLI, an editor for commit messages, and a remote host if more than one machine is involved. GUIs are fine if you can still see the graph. .gitignore keeps build output and .env files out. Signing commits is optional and useful in some orgs. Your CI credentials are separate from your Git identity.

How to get started

  1. git init a folder or clone a repository you may write to.
  2. Set a user name and email for commits if they are unset. Make a tiny change. git add the file and git commit.
  3. Create a branch, change the file again, and merge it back. Read the log as a graph (git log --oneline --graph).
  4. Add a .gitignore for dependencies and .env. Confirm git status does not show secrets.
  5. If you use a remote, push the branch and open a pull request rather than committing straight to main once more than one person is involved.
  6. Practice recovering: create a commit, then look at it with git show. Know that git reset --hard throws away uncommitted work.

Read a tutorial that makes you use the CLI for a day even if you later prefer a GUI. The vocabulary is the CLI's vocabulary.

Cautions and trade-offs

Force-pushing shared branches deletes other people's commits. Do not do it on main. Rebase is pleasant on your own branch and hostile on a branch someone else has checked out. Large files make every clone slow forever.

Commit messages that say "fix" or "wip" waste the history. Say why. And do not solve a bad commit with a second commit that contains your .env. Remove the secret from history with the understanding that anyone who cloned it already has it, then rotate the credential. History rewrite does not rotate a key.