Git & Version Control Core Git Workflow Syllabus

Core Git Workflow syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Core Git Workflow in Git & Version Control, not a summary of it.

1. 1

   Creating and Cloning Repositories

   3 topics

   • git init
   • git clone
   • Repository Structure and .gitignore
2. 2

   Recording Changes

   4 topics

   • Checking Status with git status
   • Staging Changes with git add
   • Committing with git commit
   • Removing and Moving Files
3. 3

   Viewing History

   4 topics

   • git log and Its Options
   • Filtering Commit History
   • Inspecting Changes with git diff
   • git show and git blame
4. 4

   Undoing Changes

   4 topics

   • Unstaging and Discarding Changes
   • Reverting Commits with git revert
   • Resetting with git reset
   • Recovering Lost Work with the Reflog
5. 5

   Stashing and Cleaning

   3 topics

   • Saving Work with git stash
   • Managing Multiple Stashes
   • Cleaning the Working Directory with git clean

Core Git Workflow flashcards for Git & Version Control

19 of 56 cards from the Core Git Workflow deck — real questions with worked answers.

1. What does the command `git init` do?

   It creates a new, empty Git repository in the current directory by generating a hidden `.git` subdirectory that holds all version-control data (objects, refs, config). It does not stage or commit any existing files.

2. After running `git init` in a folder with existing files, what is the state of those files?

   They are present in the working directory but untracked. Git knows nothing about them until you stage them with `git add` and commit them.

3. What is the purpose of `git clone <url>`?

   It copies an existing remote repository to your machine: it creates a directory, initializes a `.git` inside it, downloads the full history, checks out the default branch, and automatically adds the source as a remote named `origin`.

4. By default, what remote name does `git clone` assign to the source repository?

   `origin`.

5. How do you clone a repository into a directory with a custom name?

   `git clone <url> <directory-name>`. The second argument overrides the default directory name derived from the repo URL.

6. What are the three main states/areas a file can be in within Git's model?

   The working directory (modified files), the staging area/index (changes staged for the next commit), and the repository/`.git` directory (committed history).

7. What does the `.git` directory contain?

   All the metadata and object database for the repository: the object store (blobs, trees, commits, tags), refs (branches/tags), HEAD, the index, config, and hooks. Deleting it turns the folder back into an ordinary directory.

8. What is the purpose of a `.gitignore` file?

   It specifies intentionally untracked file patterns that Git should ignore, so they never appear as untracked or get accidentally staged (e.g., build artifacts, logs, secrets, dependency folders).

9. Does adding a file pattern to `.gitignore` stop Git from tracking a file that is already committed?

   No. `.gitignore` only affects untracked files. To stop tracking an already-committed file you must run `git rm --cached <file>` (and then commit) in addition to ignoring it.

10. In `.gitignore`, what do the patterns `logs/`, `*.log`, and `!important.log` mean?

    `logs/` ignores the whole logs directory; `*.log` ignores all files ending in `.log`; `!important.log` is a negation pattern that re-includes `important.log` even though `*.log` would otherwise ignore it.

11. What does `git status` show?

    The current branch, whether it is ahead/behind its upstream, and the state of files: staged changes ready to commit, unstaged modifications, and untracked files.

12. What does `git status -s` (or `--short`) produce, and how are its two status columns interpreted?

    A compact output where each file has a two-letter code: the left column is the staging-area (index) status and the right column is the working-tree status. Codes include `M` modified, `A` added, `D` deleted, `??` untracked.

13. What does `git add <file>` do?

    It stages the current content of the file into the index, marking it to be included in the next commit. It captures a snapshot of the file at the moment `add` is run.

14. What is the difference between `git add .` and `git add -A`?

    `git add -A` (`--all`) stages all changes in the whole repository including deletions, additions, and modifications. `git add .` stages changes in the current directory and below (in modern Git it also includes deletions in that path).

15. What does `git add -p` (patch mode) let you do?

    It lets you interactively review and stage individual hunks (portions) of a file's changes rather than the whole file, so you can craft focused commits.

16. If you edit a file after staging it with `git add`, what happens in `git status`?

    The file appears twice: the previously staged snapshot is listed as staged (to be committed), and the new edits appear as unstaged changes. You must `git add` again to stage the latest edits.

17. What does `git commit` do?

    It permanently records the currently staged snapshot (the index) as a new commit in the repository history, along with an author, timestamp, parent reference, and a commit message.

18. What does `git commit -m "message"` do?

    It commits the staged changes using the given message inline, without opening the configured text editor.

19. What is the effect of `git commit -a`?

    It automatically stages all already-tracked, modified and deleted files and then commits them in one step. It does NOT include untracked (new) files.

See more Core Git Workflow flashcards →

Planning Core Git Workflow for Git & Version Control

Core Git Workflow (Git & Version Control) FAQ