Version Control with Git

A marks calculation is corrected after a bug report. Renaming files final.js, final2.js and really-final.js does not clearly explain which change fixed the issue or how it relates to earlier work.

Version control records project changes and their history. Git is a version-control tool: a commit records a staged snapshot with a message and a connection to earlier history.

The working tree contains your current project files. git add copies the selected file content into the staging area, also called the index. git commit records the staged snapshot, not every current edit automatically.

Git is a tool used through terminal commands or an editor interface, not a JavaScript language feature. The commands below are real Git commands. Run them inside a new disposable practice folder, not an existing project with valuable work.

Before starting, review files and folders. These examples use JavaScript; other languages can use different syntax and rules.

Terminal commands · Create an empty school-practice folder and open a terminal there. Git must already be installed. Configure an appropriate author name and email for this practice repository only; these commands do not change global settings.

Create marks.js in your editor containing console.log(40 + 35);, then run the commands below. git status --short shows the new file before staging. git log --oneline shows a generated commit identifier followed by Add school marks total; identifiers vary.

git init
git config user.name "Practice Learner"
git config user.email "learner@example.com"
git status --short
git add marks.js
git diff --staged
git commit -m "Add school marks total"
git log --oneline

Save this content as marks.js before the real Git workflow. Running the file with Node.js displays 75. Git records the file content; it does not execute the code or certify the result.

This executable example is the project file, not a simulation of Git history. Use the commands in the preceding workflow to record it.

Terminal commands · Change marks.js to console.log((40 + 35) / 2); and save. git diff shows the working-file change. git diff --staged is empty until you stage it.

After git add marks.js, git diff --staged shows the average change. If you edit again after staging, you must stage the updated content again to include it in this commit.

git status --short
git diff
git diff --staged
git add marks.js
git diff --staged
git commit -m "Calculate average across two subjects"

The second committed version should calculate the average rather than the total. What code should marks.js contain, and when should you stage it?

A branch is a movable name for a line of commits. It helps isolate a change without inventing new numbered filenames. Merging combines histories and can require resolving conflicting edits deliberately.

A remote is a configured location for another repository. commit records locally; push sends commits to a remote, and fetch retrieves remote history. A local commit does not automatically publish your work.

These concepts extend the local workflow. Before using commands that discard edits or rewrite shared history, understand their effect and preserve valuable work.

Use .gitignore for generated files and local secrets before staging. Ignoring a file does not remove a secret already committed. If a secret was exposed, revoke or rotate it and follow the appropriate history-cleanup procedure.

Git records snapshots, not whether code is correct. Run the relevant checks and review the staged differences. A useful commit message explains the reason and resulting behavior.

A repository on one disk is not a backup strategy. Keep an appropriate separate copy or remote, and avoid destructive reset or clean commands when learning to inspect changes.

For the language or tool rules used here, see Git command documentation.

Use working files for edits, staging to select the snapshot and commits to record local history. Inspect differences, verify behavior and distinguish local history from publishing or backup.

Connect this idea with checks before recording a change and organizing tracked project files.