> For the complete documentation index, see [llms.txt](https://kipavy.gitbook.io/it-wiki/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kipavy.gitbook.io/it-wiki/git/git-basics.md).

# Git Basics

If you only learn a handful of Git commands, learn these. Everything else in this section builds on them.

### The mental model

A commit is a **snapshot** of your files at a point in time. Changes move through three places before they become a commit:

```mermaid
flowchart LR
    WD["Working Directory<br/><i>your edits</i>"] -->|git add| SA["Staging Area<br/><i>index</i>"]
    SA -->|git commit| REPO["Repository<br/><i>history</i>"]
```

* **Working directory** — the files you're editing right now.
* **Staging area (index)** — the changes you've marked to go into the next commit.
* **Repository** — the committed history.

### Starting a repo

```bash
git init                      # turn the current folder into a repo
git clone <url>               # copy an existing remote repo
```

### The everyday loop

```bash
git status                    # what changed? what's staged?
git add <file>                # stage a file (use . for everything)
git commit -m "message"       # snapshot the staged changes
git push                      # send commits to the remote
```

Pull in other people's changes before you push:

```bash
git pull                      # fetch + merge the remote into your branch
```

{% hint style="info" %}
`git pull` is really two steps: `git fetch` (download remote commits, change nothing locally) followed by `git merge` (combine them into your branch). When you want to *look* before integrating, run `git fetch` on its own first.
{% endhint %}

### Ignoring files

Create a `.gitignore` file so build output, secrets, and dependencies never get committed:

```gitignore
node_modules/
.env
dist/
*.log
```

{% hint style="warning" %}
`.gitignore` only affects **untracked** files. If something is already committed, ignoring it later won't remove it — run `git rm --cached <file>` first.
{% endhint %}

### Branches

A branch is just a movable pointer to a commit. Use one per feature or fix:

```bash
git switch -c <new-branch>    # create and switch to a new branch
git switch <branch>           # switch to an existing one
git merge <branch>            # merge another branch into the current one
```

See [Managing Branches](/it-wiki/git/managing-branches.md) for renaming, upstreams, and deletion.

### Undo & rescue

```bash
git restore <file>            # discard uncommitted changes to a file
git restore --staged <file>   # unstage, but keep the edits
git stash                     # shelve all changes to come back to later
git stash pop                 # bring the shelved changes back
```

For moving `HEAD` between commits, see [Reset and Switch](/it-wiki/git/reset-and-switch.md). For editing commits that already exist, see [Rename / Edit / Squash commit(s)](/it-wiki/git/renaming-a-pushed-commit.md).

### Merge vs. rebase (the short version)

Both combine work from two branches; they differ in the history they leave behind:

* **Merge** keeps both histories and adds a merge commit. Safe, non-destructive, but the graph can get noisy.
* **Rebase** replays your commits on top of another branch for a straight, linear history — but it *rewrites* commits, so never rebase commits others have already pulled.

A good default: **merge** to bring shared branches together, **rebase** to tidy up your own local work before sharing it.

### Tags

Tags mark a specific commit — usually a release:

```bash
git tag v1.0.0                # lightweight tag on the current commit
git tag -a v1.0.0 -m "..."    # annotated tag (recommended for releases)
git push origin v1.0.0        # tags aren't pushed by default
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://kipavy.gitbook.io/it-wiki/git/git-basics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.