KKitForma.

Language

EnglishEnglishTürkçeTurkishTool unavailable · open catalogDeutschGermanTool unavailable · open catalogEspañolSpanishTool unavailable · open catalogFrançaisFrenchTool unavailable · open catalogPortuguêsPortugueseTool unavailable · open catalogItalianoItalianTool unavailable · open catalogNederlandsDutchTool unavailable · open catalogPolskiPolishTool unavailable · open catalogРусскийRussianTool unavailable · open catalogУкраїнськаUkrainianTool unavailable · open catalogSvenskaSwedishTool unavailable · open catalogNorskNorwegianTool unavailable · open catalogDanskDanishTool unavailable · open catalogSuomiFinnishTool unavailable · open catalogČeštinaCzechTool unavailable · open catalogRomânăRomanianTool unavailable · open catalogΕλληνικάGreekTool unavailable · open catalogالعربيةArabicTool unavailable · open catalogעבריתHebrewTool unavailable · open catalogفارسیPersianTool unavailable · open catalogاردوUrduTool unavailable · open catalogहिन्दीHindiTool unavailable · open catalogবাংলাBengaliTool unavailable · open catalogதமிழ்TamilTool unavailable · open catalogతెలుగుTeluguTool unavailable · open catalogमराठीMarathiTool unavailable · open catalogગુજરાતીGujaratiTool unavailable · open catalog简体中文Chinese SimplifiedTool unavailable · open catalog繁體中文Chinese TraditionalTool unavailable · open catalog日本語JapaneseTool unavailable · open catalog한국어KoreanTool unavailable · open catalogTiếng ViệtVietnameseTool unavailable · open catalogไทยThaiTool unavailable · open catalogBahasa IndonesiaIndonesianTool unavailable · open catalogBahasa MelayuMalayTool unavailable · open catalogFilipinoFilipinoTool unavailable · open catalogKiswahiliSwahiliTool unavailable · open catalogAfrikaansAfrikaansTool unavailable · open catalogMagyarHungarianTool unavailable · open catalogБългарскиBulgarianTool unavailable · open catalogHrvatskiCroatianTool unavailable · open catalogSrpskiSerbianTool unavailable · open catalogSlovenčinaSlovakTool unavailable · open catalogSlovenščinaSlovenianTool unavailable · open catalogLietuviųLithuanianTool unavailable · open catalogLatviešuLatvianTool unavailable · open catalogEestiEstonianTool unavailable · open catalogCatalàCatalanTool unavailable · open catalogEuskaraBasqueTool unavailable · open catalog
← All learning paths

Free learning • no account required

Review and combine changes with Git

Four local exercises connect snapshots, focused branches, conflict decisions and reversible corrections. You can practice every step without a hosting account.

Explain exactly what a commit contains, review a branch, resolve a deliberate conflict and undo a bad commit while preserving history.

Suggested study time: 160 minutes, plus your project. Go at your own pace.

Before you start: prerequisites and scope
  • Complete a small web or Python project first. You should be able to edit and save a plain text file.
  • To run commands, use an existing Git 2.28+ installation, a terminal and a new empty practice folder. Reading, quizzes and workbook download need no installation.

These are local practice repositories. No remote push, hosting account, credential, paid service or automatic code execution is involved. This is an introductory collaboration workflow, not a complete treatment of rebasing, remote permissions or recovering every kind of lost file.

0/4

Completion means practice acknowledged and every quiz answer correct. It is a personal study record, not certification. All lessons remain available.

Loading this device’s progress…

Restore or reset progress

1. Separate saved, staged and committed content

By the end

  • Identify the working file, index and current commit as three different states.
  • Choose the diff that answers what the next commit will contain.

Start in a new empty folder, not an existing project. Run git init --initial-branch=main. The name and email below are local example identity settings; they are stored in this practice repository, not your global Git configuration. No network operation follows.

Saving a file changes the working tree. git add captures the chosen file content in the index. A normal git commit records that staged content. Editing the file again does not update the index automatically. Think of staging as selecting a version, not adding a permanent watch on a file.

git diff compares working content with the index; git diff --cached compares the index with the current commit. Use both before committing. A clean git diff alone does not prove there are no staged changes. Review the actual lines as well as the list of filenames.

Worked example

Create plan.txt containing daily_minutes=20 and a final newline. Stage it, then edit the working file to daily_minutes=30 without staging again. Predict the first commit.

  1. Initialize the empty folder and set the example identity locally.
  2. Save 20, run git add, then use your editor to save 30.
  3. git show :plan.txt reads the staged version and still shows 20. The ordinary diff shows 20 changing to 30.
  4. Commit without -a. HEAD contains 20; the working file remains 30 and has an uncommitted change.
git init --initial-branch=main
git config user.name "Learning Fixture"
git config user.email "learner@example.invalid"
# Save plan.txt with daily_minutes=20 before the next command.
git add -- plan.txt
# Now edit and save daily_minutes=30.
git show :plan.txt
git diff -- plan.txt
git diff --cached -- plan.txt
git commit -m "Start study plan"
git show HEAD:plan.txt
git status --short

The commit contains 20, not 30. Staging again is necessary if the intended snapshot is the newer content.

Try it yourself

Finish the intended change to 30. Stage only plan.txt, inspect its staged diff and commit it. Explain why git diff --cached is empty afterward.

  • HEAD and the working file both contain daily_minutes=30.
  • git status --short and both diff commands produce no changes.
Reveal the practice solution

Run git add -- plan.txt, git diff --cached -- plan.txt, then git commit -m "Use 30 minute sessions". The index now matches the new HEAD, so there is no staged difference. The working file also matches.

Watch for this mistake: git add does not include edits made after that command. Inspect the staged version instead of assuming a saved file is committed.

Check your understanding

Choose one answer per question. You can retry without a limit; review the explanation after checking.

1. You stage value 10, save value 12, then run a normal git commit. Which value is recorded?
2. Which command most directly reviews the changes selected for the next normal commit?

0/2 answered. Answer every question before checking.

Sources and review date
  • Git: git-add

    The index records the file contents added, independently of later working file edits. Checked: .

  • Git: git-diff

    Working tree, cached changes and three-dot merge-base comparisons. Checked: .

  • Git: git-status

    Inspect staged, unstaged and unmerged paths. Checked: .

Explanations, examples and quiz questions are original KitForma material. These links support technical facts and curriculum alignment.

Apply it: your final project

Apply the same process to a copy of your small project: make one focused branch, show its diff, merge it, deliberately commit one harmless incorrect value, then revert that single commit. Write the reason for each decision.

  • The staged diff contains only the intended change, and the branch review names the behavior being changed.
  • A conflict resolution follows an explicit requirement and leaves no conflict markers or unmerged files.
  • After the revert, the file has its prior valid contents and both the incorrect commit and corrective commit remain in the log.

The project is self-reviewed using this rubric; the site does not automatically grade your code or certify mastery.

KitForma

What would you like to do?