First local-to-remote Git sync
Published Updated
This is the Learning Atlas from Orbit. Get your invite
Git fundamentals
-
Step 1: Repository
Why this matters here
Start here because every later Git action needs a project history to act on. The learner needs to know what is being tracked before deciding what should change.
In short
A centralized storage location where your project's files and their entire revision history are kept. It acts as the single source of truth for a project's codebase.
-
Step 2: Working directory
Why this matters here
This is where the learner's unsaved edits first appear, so it connects the abstract repository to the files they can see and change.
In short
The actual files and folders you see and edit on your computer's file system for a specific Git repository.
-
Step 3: Staging area
Why this matters here
After edits exist, staging teaches the learner how to choose which pieces belong in the next saved unit instead of committing everything blindly.
In short
A middle ground where you prepare and gather specific modified files before wrapping them up into a permanent commit.
-
Step 4: Commit
Why this matters here
Once changes are staged, committing turns a loose set of edits into a named checkpoint that other Git operations can move, share, or undo.
In short
A saved snapshot of your project's files at a specific point in time. It permanently records changes made to the codebase along with a descriptive message.
-
Step 5: Remote
Why this matters here
A local checkpoint is not yet collaboration-ready; introducing the remote explains where the shared copy of the work will live.
In short
A version of your project that is hosted on the internet or network, used for syncing code and collaborating with other developers.
-
Step 6: Push
Why this matters here
Push is the handoff from private progress to shared history, making it the natural endpoint for a first successful Git loop.
In short
The act of uploading your local repository's committed changes to a remote repository server.