Git basics: commits, branches and reviewing changes

When configuration changes break a service, you need to know what changed and return to a known version. Git records file snapshots, called commits, with a history the team can inspect and share.

A branch lets you develop changes along a named line of history. Your working tree is the set of files you are editing, including changes not yet committed. A remote repository is a shared copy, not an automatic backup of every local edit. Use small commits and review the differences before sharing infrastructure changes.

Try it in a lab

Create a disposable repository, make two small commits on a branch and inspect the diff against its starting point. Create and resolve a deliberate text conflict, then explain the resulting history.

Check your understanding

Show which changes are uncommitted, which are committed locally and which have been shared. Describe how to revert a shared change while preserving its history.

Before you start

Avoid force-pushing shared branches during a learning exercise. Do not add secrets to a commit; deleting them in a later commit does not remove them from history.

Read the official guide

Use the project documentation for version-specific commands and prerequisites. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.