# The daily loop

## Clone once

```bash
git clone git@codebahn.net:acme/app.git
cd app
```

## See what changed

```bash
git status
```

```bash
git diff
```

`git status` lists which files changed. `git diff` shows the changed lines.

## Commit

```bash
git add README.md
git commit -m "Explain how to run the app"
```

The message is for whoever reads the history next year, which may be you. Five rules cover almost everything:

- Write the subject as an instruction: "Explain how to run the app", not "Explained" or "Explains".
- Keep the subject under 50 characters, start it with a capital letter, and leave off the period.
- Put a blank line after the subject.
- Use the body to say why, and anything a reader would not guess from the change itself. Wrap it at 72 characters.
- Commit one change at a time, so the subject can be honest.

A second `-m` adds the body:

```bash
git commit -m "Reject empty usernames" -m "The form let blank names through and created accounts nobody could use."
```

In the history it reads like this:

```text
Reject empty usernames

The form let blank names through and created accounts nobody could use.
```

Some teams prefix the subject with a type, `fix:` or `feat:`, so tools can build changelogs and version numbers from the history. That convention is [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). If your team uses it, follow it; the rules above still apply to the rest of the line. The [Pro Git commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) explain the reasoning.

## Share and update

```bash
git push
```

```bash
git pull
```

While you worked, a teammate pushed a change of their own. `git pull` fetches it and merges it into your branch.

## Read history

```bash
git log --oneline -5
```

Each line is one commit: a short hash and its subject.

Git basics is licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/): copy it, adapt it, keep the credit.