Clone, stage, commit, push and pull
You clone a repository to get your own copy, edit files, stage the changes you want with git add, record them with git commit, and share them with git push. git pull brings in other people's changes. git status tells you where you are at every step.
The everyday loop
$ git clone https://github.com/acme/payroll.git $ cd payroll (edit src/calc.cbl in your editor) $ git status modified: src/calc.cbl $ git diff # what exactly changed? $ git add src/calc.cbl $ git commit -m "Round overtime to two decimals" [main 3f9c2a1] Round overtime to two decimals $ git push
Three places a change can be
The staging area lets you choose exactly what goes into a commit. If you fixed a bug and also tidied an unrelated file, you can stage and commit the bug fix on its own, with its own message. git add . stages everything that changed in the current folder, so check git status before you use it.
Commands you will use every day
| Command | What it does |
|---|---|
git clone URL | Copy a remote repository, with its full history, to your machine |
git status | What has changed, what is staged, and which branch you are on |
git diff | The exact lines changed and not yet staged. git diff --staged shows what is staged |
git add FILE | Stage a change for the next commit |
git commit -m "msg" | Record the staged changes as a commit |
git log --oneline | The history, one line per commit |
git push | Send your new commits to the remote repository |
git pull | Fetch other people's commits and merge them into your branch |
Good commit messages
Write the message for the colleague who reads the history in a year's time. Say *why*, not just *what*: 'Round overtime to two decimals (payroll ticket 4411)' is useful, 'fix' is not. Keep each commit to one logical change, so that it can be reviewed, and reverted if necessary, on its own.
Files that should not be tracked
A .gitignore file lists patterns Git should ignore, such as build outputs, logs, editor settings and local configuration: *.log, build/, .vscode/. Ignored files never show up in git status, so they cannot be committed by accident.
You changed README.md and want it in your next commit. Which command stages it?
Show a hint
Staging uses the add command.
Show the solution
git add README.md, then git commit -m "...".
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
git add . can sweep in logs, build outputs or local configuration. Look first, and use .gitignore.
'update' or 'fix' tells nobody anything. Say why the change was made.
--force replaces the remote history with yours and can delete colleagues' commits. Pull and merge instead.
What you will see at work
- Your first day on a Git team usually starts with
git cloneand ends with your first commit on a branch. - Many teams link commits to tickets by putting the ticket number in the message.
- Pipelines usually start automatically when you push, so a push is often the moment a build begins.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.