Git, GitHub, Branching and Collaborative Version Control

version control

Version control records named snapshots and their ancestry so changes can be compared, attributed, combined, reviewed and restored.

Git repository

A Git repository stores content-addressed objects and references representing commits, trees, files, branches and tags.

working tree and index

The working tree contains checked-out files, while the index is the proposed snapshot that the next commit will record.

commit

A Git commit records a project tree, parent commit references, author and committer metadata and a message; its identifier is derived from its content.

branch

A Git branch is a movable reference to a commit, allowing a line of development to advance independently before it is merged or rebased.

merge conflict

A merge conflict occurs when Git cannot automatically combine changes to the same content or path

rebase

Rebase copies a sequence of commits onto a new base, creating new commit identities and requiring care when the original history is already shared.

remote fetch pull push

fetch downloads remote objects and updates remote-tracking references, pull fetches then integrates and push asks a remote to update its references.

GitHub pull request

A pull request presents a branch difference for discussion, review, automated checks and controlled integration

tag and release

A Git tag names a particular object, usually a commit; a hosted release associates that version with notes and distributable artifacts.

Git Snapshots and Branches

Git stores snapshots as commits. A commit records a tree, metadata and one or more parent commits. A branch is a movable name pointing to a commit. HEAD identifies the checked-out branch or commit. The working tree contains editable files while the index stages the exact content intended for the next commit. git diff shows unstaged changes and git diff --staged shows the proposed commit.

A fast-forward merge moves a branch pointer when no divergence exists. A three-way merge combines diverged histories and may create a merge commit. Rebase copies commits onto a new base and gives them new identities. Conflicts require a developer to understand both intentions, edit the final result, stage it and continue. Tests are needed because a textually clean resolution can still be wrong.

Remotes and Team Work

A remote is a named repository location. git fetch downloads objects and updates remote-tracking names without changing the working branch. git pull fetches and then integrates. git push asks the remote to update a branch. Hosting platforms place pull requests, review and automated checks around Git. A sound workflow uses focused commits, short-lived branches, reviewable diffs and protected important branches. Secrets must never be committed because a later deletion does not erase earlier history.

History Inspection and Recovery

git log --graph --decorate --oneline --all shows commit relationships and names. git show examines one commit. git blame associates current lines with commits but does not by itself explain why a change was made. git bisect performs a binary search through history when a test can identify good and bad revisions.

Restoring a file in the working tree, unstaging content and undoing a published change are different operations. git restore can replace working or staged content. git revert creates a new commit that applies the inverse of an earlier commit and is suitable for shared history. git reset moves a branch and may also change the index or working tree depending on mode, so it requires care. The reflog records recent local movements of names and can recover commits that no branch currently references.

Tags name important commits such as releases. Annotated tags carry metadata and can be signed. Remote-tracking branches record the last fetched remote state. A non-fast-forward push is normally rejected because it would discard remote-visible history. Force-with-lease adds a safety condition when history rewriting is intentional on an agreed branch.