Loading...
Loading...
Cookie choices
WoHoTech uses essential cookies for login and site features. Non-essential analytics and advertising scripts load only after you accept them.
Read privacy policyVersion control basics, branching, collaboration, and daily Git/GitHub workflows. Use this page as a focused learning resource for git concepts, interview preparation, and practical revision.
In the landscape of modern software development, two tools stand above all others in terms of daily usage by professional developers:GitandGitHub. These two distinct but deeply intertwined technologies form the backbone of virtually all collaborative software development, open source contribution, DevOps pipelines, and professional code management in 2026. Understanding them thoroughly is not optional for anyone serious about a career in technology - it is as fundamental as knowing how to type.
Git is adistributed version control system(DVCS) created by Linus Torvalds in 2005. It tracks changes to files over time, enables multiple developers to work on the same codebase simultaneously without conflicts, provides the ability to roll back to any previous state, and maintains a complete, verifiable history of every modification ever made to a project. Git is local-first - the entire project history lives on your machine - and connects to remote servers for collaboration and backup.
GitHub, owned by Microsoft since 2018, is the world's largest platform for hosting Git repositories in the cloud. But GitHub is far more than a Git host: it is an integrated development platform that includes pull requests and code review, CI/CD with GitHub Actions, project management with GitHub Projects, AI-assisted coding with GitHub Copilot, security scanning and vulnerability management, package hosting, Pages for static site deployment, and a rich social layer that connects 100+ million developers worldwide.
The dominance of Git and GitHub has only strengthened through the mid-2020s. The StackOverflow Developer Survey consistently shows Git as the most widely used tool in software development, with usage rates above 95% among professional developers. GitHub hosts over 420 million repositories and serves as the primary collaboration platform for the majority of the world's open source software.
Several trends have reinforced their importance. The rise of AI coding tools - particularly GitHub Copilot - has made GitHub even more central to the developer workflow, as AI assistance is now directly integrated into the repository and code review process. The shift to cloud-native development and DevOps has elevated GitHub Actions as a primary CI/CD platform, competing directly with Jenkins, CircleCI, and GitLab CI. And the increase in distributed team collaboration following the work-from-home shift has made remote-first tools like GitHub essential infrastructure for software teams globally.
📊 Git & GitHub in 2026
GitHub hosts over 420 million repositories, with 100+ million developers worldwide. GitHub Actions is used in over 60% of public repositories for CI/CD. GitHub Copilot, used by over 1.3 million developers (as of 2025), generates a meaningful percentage of code in repositories where it is enabled. Git is used by over 95% of professional developers as their primary version control system.
This distinction is critical and frequently confused by newcomers.Git is the version control tool- it lives on your local machine and manages your project history.GitHub is a cloud platform that hosts Git repositoriesand adds collaboration features on top. You can use Git without GitHub (with GitLab, Bitbucket, Azure DevOps, or self-hosted Gitea), and GitHub without deep Git knowledge (though this produces bad habits). For professional development, you need to understand both deeply.
Other Git hosting services exist and have meaningful market share: GitLab (strong in self-hosted and enterprise settings), Bitbucket (popular in Atlassian/Jira shops), and Azure DevOps (dominant in Microsoft ecosystem organizations). However, GitHub's network effects, GitHub Actions ecosystem, Copilot integration, and open source community make it the primary platform this guide focuses on, with principles that transfer to all Git platforms.
The history of version control systems is a story of evolving needs, paradigm shifts, and occasionally dramatic controversies. Understanding this history provides context for why Git is designed the way it is and why certain decisions that seem strange at first (like the distributed model or Git's content-addressed storage) make excellent sense given the problems they were designed to solve.
Version control did not begin with Git. The field has a rich history going back decades. SCCS (Source Code Control System), developed at Bell Labs in 1972, was the first widely-used version control system. RCS (Revision Control System, 1982) improved on it with more capabilities but still operated on individual files rather than entire projects. CVS (Concurrent Versions System, 1986) introduced the concept of a central repository and allowed multiple developers to work concurrently, but it was notoriously poor at handling file renames and lacked atomic commits.
Subversion (SVN, 2000) addressed many of CVS's shortcomings, introducing atomic commits, better binary file handling, and proper versioning of directory operations. SVN dominated corporate software development throughout the 2000s and is still used in many legacy environments today. However, SVN is centralized - there is one server, and if the server is unavailable, developers cannot commit, compare history, or branch. This single point of failure would prove problematic.
The Linux kernel development team used BitKeeper, a proprietary distributed version control system, for free under a special agreement from 2002 to 2005. When that agreement was revoked following a licensing controversy, the kernel developers needed an alternative. None of the available free tools - CVS, SVN, Arch, Monotone - met their demanding requirements: handling the scale of the Linux kernel (thousands of patches per release, hundreds of developers), verifying data integrity cryptographically, and supporting highly distributed non-linear development.
Linus Torvalds, dissatisfied with all available options, wrote Git in just over two weeks in April 2005. His design goals were explicit: speed, simplicity of design, strong support for non-linear development (thousands of parallel branches), fully distributed operation, and the ability to handle large projects like the Linux kernel efficiently. Git's first commit was made on April 7, 2005, and within three months it was managing the Linux kernel source.
GitHub was founded in April 2008 by Tom Preston-Werner, Chris Wanstrath, PJ Hyett, and Scott Chacon. Their insight was that Git needed a beautiful, social interface to unlock its full potential for open source collaboration. Features like the fork model (allowing anyone to create their own copy of any public repository), the pull request workflow (enabling code contribution without direct repository access), and the social feed of developer activity transformed how open source software was built.
GitHub's growth was explosive. Within four years it had become the dominant platform for open source development, hosting major projects including Linux kernel mirrors, Ruby on Rails, jQuery, Bootstrap, Node.js, and later React, Angular, Vue, TensorFlow, and essentially every significant open source project. In June 2018, Microsoft acquired GitHub for $7.5 billion - a decision that initially sparked concern in the developer community but has largely been validated by Microsoft's continued open-source-friendly stewardship.
| Year | Milestone | Significance | | --- | --- | --- | | 1972 | SCCS released | First version control system | | 1986 | CVS released | First concurrent multi-user VCS | | 2000 | Subversion (SVN) | Improved centralized VCS, dominated 2000s | | 2005 | Git created by Torvalds | Distributed VCS revolution begins | | 2008 | GitHub founded | Social coding + open source platform | | 2011 | GitHub Actions precursor | First CI/CD integrations | | 2018 | Microsoft acquires GitHub | $7.5B acquisition, maintained independence | | 2019 | GitHub Actions GA | Native CI/CD in every repository | | 2021 | GitHub Copilot preview | AI code generation enters mainstream | | 2022 | Copilot GA, Codespaces GA | Cloud dev environments and AI coding | | 2023-25 | Copilot Workspace, AI features | AI permeates every GitHub workflow | | 2026 | Git 2.50+, GitHub 2026 features | Performance, security, AI integration |
Before using Git, you need it installed on your system and configured with your identity. In 2026, Git 2.40+ is standard across all major operating systems, and the installation process is straightforward. Proper configuration - particularly your name, email, and default behaviors - affects how your commits appear in history and how certain operations behave.
Shell - Installation
Shell - git config
Shell - SSH Setup
# Generate SSH key (Ed25519 is recommended in 2026)
ssh-keygen -t ed25519 -C "you@example.com"
# Start ssh-agent and add key
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
# Copy public key to clipboard
cat ~/.ssh/id_ed25519.pub # then paste to GitHub → Settings → SSH Keys
# macOS shortcut:
pbcopy < ~/.ssh/id_ed25519.pub
# Test connection
ssh -T git@github.com
# Expected: Hi username! You've successfully authenticated...
# ~/.ssh/config for multiple accounts
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personalGit's design is fundamentally different from centralized version control systems, and understanding its core concepts is essential for using it effectively. Many Git problems that confuse beginners stem from a surface-level understanding of commands without comprehending the underlying model. This section builds that mental model.
Git manages three distinct "trees" (logical areas) that represent different states of your files:
git add. This intermediate layer is one of Git's most distinctive and powerful features.Diagram - Git Three Trees
Git is fundamentally acontent-addressed filesystem. Everything stored in Git is identified by a SHA-1 (or SHA-256 in newer Git versions) hash of its content. There are four types of Git objects:
Abranchin Git is simply a lightweight, movable pointer to a specific commit. When you make a new commit, the current branch pointer automatically moves forward to point to the new commit. This is radically different from other VCS systems where branches are heavyweight copies of the entire project.
HEADis a special reference that points to the currently checked-out branch (or directly to a commit in "detached HEAD" state). When you're on themainbranch, HEAD → main → latest-commit-hash.
Shell - Understanding References
The.gitdirectory at the root of your repository IS your Git repository. Everything Git knows about your project - every commit, every blob, every branch reference, every configuration - lives here. Understanding its structure demystifies many Git operations.
.git Structure
This section covers every Git command you will use daily, organized by workflow stage. These are the building blocks of all Git usage, and mastering them with their important flags and options is the foundation of Git proficiency.
Shell - Init & Clone
| git clone https | //github.com/user/repo.git |
| git clone git@github.com | user/repo.git # SSH |
| git clone https | //github.com/user/repo.git my-folder # custom dir |
| git clone --depth 1 https | //github.com/user/repo.git |
| git clone --branch develop https | //github.com/user/repo.git |
| git clone --filter=blob | none --sparse https://github.com/user/repo.git |
Shell - Stage & Commit
| git status -s # short format | M=modified, A=added, ??=untracked |
| git add -p # interactive | stage hunks selectively |
| git commit -m "feat | add user authentication" |
| git commit -am "fix | correct typo" # add+commit tracked files |
Shell - git log
.gitignore - Patterns
Branching is where Git's power becomes fully apparent. Because branches are just lightweight pointers to commits, creating, switching, and deleting branches in Git is nearly instantaneous and costs almost nothing in terms of disk space. This enables a workflow style that is simply not practical with centralized VCS systems: developers create a new branch for every feature, bug fix, experiment, and code review - and merge or discard them freely.
Shell - Branching
Shell - Merging
| # Result | main pointer moves forward - no merge commit |
| # Result | merge commit created - preserves branch existence in history |
| # Squash merge: all branch commits | one commit on main |
| git commit -m "feat | add login feature" |
Shell - Conflict Resolution
# When a conflict occurs, Git marks the file:
<<<<<<< HEAD (current branch)
const greeting = "Hello, World!";
=======
const greeting = "Hi there!";
>>>>>>> feature/new-greeting (incoming branch)
# Steps to resolve:
# 1. Open conflicted files, manually choose/combine
# 2. Remove all conflict markers (<<<<<<< ======= >>>>>>>)
# 3. Stage the resolved files
git add src/greeting.js
# 4. Complete the merge
git commit
# Tools for visual conflict resolution
git mergetool # opens configured mergetool
git config --global merge.tool vimdiff
git config --global merge.tool "code --wait"
# Choose entire version from one side
git checkout --ours filename.js # keep current branch version
git checkout --theirs filename.js # keep incoming branch versionRebasing is an alternative to merging that rewrites commit history by replaying commits from one branch onto another. The result is a linear history that is cleaner and easier to read, but it rewrites commit hashes - which means it shouldnever be used on commits that have already been shared with others(the "golden rule of rebasing").
Shell - Rebase
Remote repositories are versions of your project hosted on a network or the internet. They enable collaboration: multiple developers can push their work to a shared remote and pull changes from others. In Git's distributed model, there is no central "source of truth" by protocol - but in practice, teams designate one remote (usually namedorigin, typically on GitHub) as the canonical repository.
Shell - Remote Operations
| git remote add origin git@github.com | user/repo.git |
| # Fetch | download remote changes WITHOUT merging |
| # Pull | fetch + merge (or rebase if configured) |
Beyond the everyday commands, Git provides a powerful set of advanced operations that every professional developer should have in their toolkit. These operations - stashing, cherry-picking, bisect, worktrees, and reflog - solve specific problems elegantly and can save hours of work when used appropriately.
Shell - git stash
Shell - cherry-pick
Shell - git bisect
# Binary search through history to find which commit introduced a bug
git bisect start
git bisect bad # current commit has the bug
git bisect good v2.0 # this tag was good
# Git checks out a commit halfway between - you test it:
# If the bug exists: git bisect bad
# If no bug: git bisect good
# Git narrows down to the exact commit in O(log n) steps
git bisect reset # end bisect, return to HEAD
# Automate with a test script
git bisect run npm test # auto-bisect using test resultThe reflog is Git's undo history for HEAD movements. Even if you accidentally delete a branch, reset incorrectly, or make some other mistake, the reflog almost always lets you recover, because Git retains all commits for at least 30 days (by default) before garbage collecting them.
Shell - git reflog
| # a1b2c3d (HEAD | main) HEAD@{0}: commit: feat: add dashboard |
| # b2c3d4e HEAD@{1} | checkout: moving from feature to main |
| # c3d4e5f HEAD@{2} | commit: WIP: dashboard layout |
Shell - Tags
Beyond individual commands, professional Git usage requires adopting a consistent team workflow - a shared agreement about how branches are created, named, merged, and deleted, and how releases are managed. Several well-established workflows exist, each with different tradeoffs in terms of complexity, safety, and flexibility.
GitHub Flow is the simplest production-ready workflow and is used by GitHub itself and millions of teams globally. It is based on one rule:themainbranch is always deployable. Everything else follows from this principle.
GitHub Flow Process
| git commit -m "feat | add JWT token validation middleware" |
| git commit -m "feat | implement login endpoint" |
| git commit -m "test | add authentication unit tests" |
| # | Request code review |
| # | CI/CD checks run automatically |
| # | Discuss changes, make revisions |
| # Options | merge commit / squash / rebase |
Gitflow, introduced by Vincent Driessen in 2010, uses multiple long-lived branches to support parallel development, release management, and hotfixing. It is more complex than GitHub Flow but useful for projects with formal release cycles and multiple maintained versions.
Gitflow Branches
Trunk-Based Development (TBD) is increasingly favored by high-performing teams and recommended by the DevOps Research and Assessment (DORA) program. In TBD, all developers integrate their work to the main trunk (main branch) at least once per day, using feature flags to hide incomplete features from users. This approach reduces integration pain, enables true continuous integration, and keeps the codebase in a constantly deployable state.
Commit Message Convention
| # Format | type(scope): description |
| feat(auth) | add OAuth2 Google sign-in support |
| fix(api) | resolve null pointer in user endpoint |
| docs(readme) | update installation instructions |
| style(ui) | fix button alignment on mobile |
| refactor(db) | extract query builder into service |
| test(auth) | add integration tests for JWT validation |
| chore(deps) | update dependencies to latest versions |
| perf(images) | lazy load below-fold product images |
| ci(actions) | add Node.js 22 to test matrix |
| build(docker) | optimize production image layers |
| # Breaking change | add "!" after type |
| feat(api)! | remove deprecated v1 endpoints |
| feat(auth) | implement multi-factor authentication |
| Co-authored-by | Alice Smith <alice@example.com> |
A GitHub repository is much more than a remote Git host. It is a collaborative workspace with features for documentation, project management, access control, automated workflows, and community engagement. Understanding how to configure and manage repositories effectively is as important as Git command knowledge.
Branch protection rules are one of the most important GitHub features for maintaining code quality and preventing accidents on critical branches. They enforce requirements before code can be merged to protected branches likemain.
Branch Protection - Key Settings
| Settings | Branches → Add rule for branch: main |
| ✅ Require approvals | 1 (or 2 for critical) |
| ✓ Status checks | ci/build, ci/test, ci/lint |
CODEOWNERS - Example
| # Format | pattern owner1 owner2 |
| # Backend | API and services |
| # Frontend | components and pages |
The Pull Request (PR) workflow is GitHub's most important contribution to collaborative software development. A pull request is a formal proposal to merge changes from one branch into another, accompanied by a discussion thread, automated checks, and a code review process. In 2026, PRs have evolved significantly with AI-assisted review summaries, better diff tools, and deeper CI integration.
Markdown - PR Template
| Before | After |
|---|---|
| [img] | [img] |
Effective code review is a skill that goes beyond finding bugs. Great reviewers improve the entire team's capabilities, not just the code quality of individual PRs. In 2026, GitHub's review features include line comments, suggestion blocks (reviewers can propose specific code changes that authors can apply with one click), AI-generated PR summaries via Copilot, and batch review submission to avoid notification overload.
GitHub - Suggested Code Change
# Reviewer leaves a suggestion in a line comment:
'''suggestion
const user = await UserService.findById(req.params.id);
if (!user) throw new NotFoundError('User not found');
'''
# Author can click "Apply suggestion" to commit the change directly
# Multiple suggestions can be batched into a single commit💡 Review Principle
The best code review comments explain thewhybehind suggestions, not just thewhat. "Use a Map here instead of an object for O(1) lookup time with arbitrary keys" is far more useful than "change this to Map". Pair feedback with educational context to grow the team's capabilities, not just fix the immediate code.
GitHub Actions is GitHub's native CI/CD (Continuous Integration / Continuous Deployment) platform, introduced in 2018 and becoming generally available in 2019. It has rapidly become one of the most widely used CI/CD systems in the world, displacing standalone tools like Jenkins, Travis CI, and CircleCI for many teams. Actions runs automated workflows in response to GitHub events - pushes, pull requests, scheduled times, manual triggers, and dozens more.
YAML - .github/workflows/ci.yml
| name | CI Pipeline |
| branches | [main, develop] |
| branches | [main] |
| workflow_dispatch | # manual trigger |
| NODE_VERSION | '22' |
| name | Lint |
| runs-on | ubuntu-latest |
| - uses | actions/checkout@v4 |
| - uses | actions/setup-node@v4 |
| node-version | ${{ env.NODE_VERSION }} |
| cache | 'npm' |
| - run | npm ci |
| - run | npm run lint |
| name | Test |
| runs-on | ubuntu-latest |
| needs | lint |
| node-version | [20, 22] # test on multiple versions |
| - uses | actions/checkout@v4 |
| - uses | actions/setup-node@v4 |
| node-version | ${{ matrix.node-version }} |
| cache | 'npm' |
| - run | npm ci |
| - run | npm test -- --coverage |
| - uses | codecov/codecov-action@v3 |
| token | ${{ secrets.CODECOV_TOKEN }} |
| name | Build |
| runs-on | ubuntu-latest |
| needs | test |
| - uses | actions/checkout@v4 |
| - uses | actions/setup-node@v4 |
| with | { node-version: ${{ env.NODE_VERSION }}, cache: 'npm' } |
| - run | npm ci |
| - run | npm run build |
| - uses | actions/upload-artifact@v4 |
| name | build-dist |
| path | dist/ |
| retention-days | 7 |
| name | Deploy to Production |
| runs-on | ubuntu-latest |
| needs | build |
| if | github.ref == 'refs/heads/main' && github.event_name == 'push' |
| name | production |
| url | https://myapp.example.com |
| - uses | actions/download-artifact@v4 |
| with | { name: build-dist, path: dist } |
| - name | Deploy to server |
| DEPLOY_KEY | ${{ secrets.DEPLOY_SSH_KEY }} |
| DEPLOY_HOST | ${{ secrets.DEPLOY_HOST }} |
| run | | |
| rsync -avz -e "ssh -i deploy_key" dist/ user@$DEPLOY_HOST | /var/www/app/ |
YAML - Composite Action
| name | 'Setup Node.js with cache' |
| description | 'Checkout, setup Node, and restore npm cache' |
| description | 'Node.js version' |
| required | false |
| default | '22' |
| using | 'composite' |
| - uses | actions/checkout@v4 |
| - uses | actions/setup-node@v4 |
| node-version | ${{ inputs.node-version }} |
| cache | 'npm' |
| - run | npm ci |
| shell | bash |
| - uses | ./.github/actions/setup-and-cache |
| node-version | '22' |
GitHub Copilot, powered by OpenAI's Codex model and launched in 2021, has fundamentally changed how many developers write code. In 2026, Copilot has evolved from a single autocomplete feature to a comprehensive AI development suite that integrates into every phase of the software development lifecycle. Understanding how to use Copilot effectively - and its limitations - is a valuable skill for modern developers.
| Feature | Description | Where Available | | --- | --- | --- | | Copilot Completions | Inline code suggestions as you type | VS Code, JetBrains, Vim, GitHub.com | | Copilot Chat | Conversational AI for code questions, explanations, refactoring | IDEs, GitHub.com, mobile | | Copilot for PRs | AI-generated PR descriptions and summaries | GitHub.com | | Copilot Workspace | AI-assisted multi-file editing from issue to PR | GitHub.com (beta) | | Copilot CLI | Shell command suggestions in terminal | Terminal (gh extension) | | Copilot Review | AI-powered code review suggestions in PRs | GitHub.com | | Copilot Autofix | Automatic security vulnerability fixes | GitHub Advanced Security |
TypeScript - Copilot Patterns
| string, | |
| userId | string |
| ) | Promise<void> { |
| principal | number, |
| rate | number, |
| years | number, |
| compoundsPerYear | number = 12 |
| ) | number { |
| // Copilot confidently generates | principal * Math.pow(1 + rate/compoundsPerYear, compoundsPerYear * years) |
| // Select code | Ctrl+I → "/refactor to use async/await" |
⚠️ Copilot Limitations
GitHub Copilot can generate plausible-looking code that is subtly wrong, outdated, or insecure. Always review every suggestion critically. Never accept security-sensitive code (authentication, encryption, authorization) from Copilot without expert review. Copilot's knowledge has a training cutoff and may suggest deprecated libraries or APIs. Use it as a productivity multiplier, not a replacement for understanding.
GitHub Pages is a static site hosting service that serves files directly from a GitHub repository. It supports custom domains, HTTPS, and integration with GitHub Actions for automated deployments. In 2026, GitHub Pages with Actions-based deployment has become a popular choice for documentation sites, personal portfolios, project showcases, and even simple web applications.
YAML - Deploy to GitHub Pages
| name | Deploy to GitHub Pages |
| branches | [main] |
| contents | read |
| pages | write |
| id-token | write |
| group | pages |
| cancel-in-progress | false |
| runs-on | ubuntu-latest |
| - uses | actions/checkout@v4 |
| - uses | actions/setup-node@v4 |
| with | { node-version: '22', cache: 'npm' } |
| - run | npm ci |
| - run | npm run build # generates ./dist or ./out |
| - uses | actions/configure-pages@v4 |
| - uses | actions/upload-pages-artifact@v3 |
| path | './dist' |
| name | github-pages |
| url | ${{ steps.deployment.outputs.page_url }} |
| runs-on | ubuntu-latest |
| needs | build |
| - name | Deploy to GitHub Pages |
| id | deployment |
| uses | actions/deploy-pages@v4 |
GitHub has invested heavily in security tooling, making it possible for repositories to automatically detect vulnerabilities in dependencies, scan for secrets accidentally committed to code, analyze code for security issues, and receive automated pull requests with fixes. In 2026, GitHub's security suite (GitHub Advanced Security, available free for public repos) is a comprehensive application security platform.
YAML - .github/dependabot.yml
| version | 2 |
| - package-ecosystem | "npm" |
| directory | "/" |
| interval | "weekly" |
| day | "monday" |
| time | "09:00" |
| timezone | "Asia/Kolkata" |
| open-pull-requests-limit | 5 |
| patterns | ["@types/*", "eslint*", "prettier*"] |
| patterns | ["jest*", "vitest*", "@testing-library/*"] |
| - package-ecosystem | "github-actions" |
| directory | "/" |
| interval | "weekly" |
| - package-ecosystem | "docker" |
| directory | "/docker" |
| interval | "monthly" |
YAML - CodeQL Analysis Workflow
| name | CodeQL Security Analysis |
| branches | [main] |
| branches | [main] |
| - cron | '30 4 * * 1' # Every Monday at 4:30 UTC |
| name | Analyze (${{ matrix.language }}) |
| runs-on | ubuntu-latest |
| security-events | write |
| packages | read |
| language | [javascript-typescript, python] |
| - uses | actions/checkout@v4 |
| - uses | github/codeql-action/init@v3 |
| languages | ${{ matrix.language }} |
| queries | security-extended # use extended security queries |
| - uses | github/codeql-action/autobuild@v3 |
| - uses | github/codeql-action/analyze@v3 |
| category | "/language:${{ matrix.language }}" |
GitHub Issues and Projects form an integrated project management system directly connected to your code. Unlike external project management tools, issues are directly linked to commits, branches, and pull requests - creating a seamless traceability chain from requirements to deployed code.
YAML - Bug Report Template
| name | 🐛 Bug Report |
| description | Report a reproducible bug |
| labels | ["bug", "triage-needed"] |
| assignees | [] |
| - type | markdown |
| value | "Thanks for reporting a bug! Please fill this out." |
| - type | textarea |
| id | description |
| label | Bug Description |
| description | Clear description of the bug |
| placeholder | "When I click the login button..." |
| required | true |
| - type | textarea |
| id | reproduction |
| label | Steps to Reproduce |
| value | | |
| required | true |
| - type | textarea |
| id | expected |
| label | Expected Behavior |
| required | true |
| - type | dropdown |
| id | severity |
| label | Severity |
| required | true |
| - type | input |
| id | environment |
| label | Environment |
| placeholder | "OS: macOS 15, Browser: Chrome 130, Version: 2.1.0" |
Understanding Git's internal object model transforms your mental model of what Git operations actually do. When you understand that every object in Git is immutable, content-addressed, and connected by a directed acyclic graph (DAG) of references, commands like rebase, cherry-pick, and reset become intuitive rather than mysterious.
Shell - Git Plumbing
Git hooks are scripts that run automatically at specific points in the Git workflow - before a commit, after a push, before a merge, and many others. They enable teams to enforce code quality standards, run tests, check commit message formats, and automate tasks without requiring developers to remember to run these checks manually.
Shell - Git Hooks
Shell + JSON - Husky Setup
| "lint-staged" | { |
| "*.{js,ts,jsx,tsx}" | [ |
| "*.{css,scss,md,json}" | [ |
| "*.{js,ts,jsx,tsx}" | [ |
As organizations grow, many teams adopt monorepos - single Git repositories containing multiple related projects, services, or packages. This approach has significant advantages for code sharing, atomic changes across multiple services, and unified tooling, but it introduces challenges for Git performance and workflow management that require specialized tooling.
Shell - Sparse Checkout
| Tool | Language | Key Features | Best For | | --- | --- | --- | --- | | Nx | JS/TS | Affected detection, caching, distributed execution | Angular, React, Node.js | | Turborepo | JS/TS | Incremental builds, remote caching, pipeline config | Next.js, React, Node.js | | pnpm workspaces | JS/TS | Efficient linking, workspace protocol | Any JS/TS monorepo | | Lerna | JS/TS | Package versioning, publish automation | Library monorepos | | Bazel | Multi-lang | Hermetic builds, distributed caching, any language | Google-scale monorepos |
Every Git user eventually encounters situations that seem dire: accidentally committed secrets, pushed to the wrong branch, deleted important work, corrupted history. Git's design - particularly the reflog and the fact that committed objects are retained for weeks - means that most mistakes are recoverable if you act before Git's garbage collection runs.
Shell - Recovery Scenarios
| # SCENARIO 1 | Accidentally committed to wrong branch |
| # SCENARIO 2 | Reset too far (lost commits) |
| # SCENARIO 3 | Committed secrets (before push) |
| # SCENARIO 4 | Committed secrets (after push) - CRITICAL |
| # SCENARIO 5 | Deleted branch (not yet GC'd) |
| # SCENARIO 6 | Resolve diverged branches |
🚨 Warning: Force Push
git push --forcerewrites the remote branch history and can destroy your teammates' work if they've based commits on the overwritten history. Always prefer--force-with-leasewhich fails if the remote has changed since you last fetched.Never force-push to shared branches like main or developwithout team consensus and proper backups.
The trajectory of both Git and GitHub points toward several clear themes for 2027 and beyond: deeper AI integration at every stage of the development workflow, better performance for increasingly large repositories, improved security tooling, and tighter integration with cloud development environments that blur the line between local and remote development.
Git has used SHA-1 as its hashing algorithm since its creation. While no practical SHA-1 collision attack against Git has been executed (Git uses SHA-1 differently from how the broken collision attacks work), the industry has been moving toward stronger cryptographic primitives. Git 2.29+ supports SHA-256 as an experimental alternative, and by 2027, SHA-256 is expected to become the default for new repositories, with improved migration tools for converting existing repositories.
GitHub Copilot Workspace, announced in 2024, represents a vision of AI-native development where you describe what you want to build in natural language - starting from a GitHub Issue - and the AI generates a complete plan, creates or modifies multiple files, writes tests, and submits a pull request for review. By 2027, this workflow is expected to be out of beta and in widespread use for routine feature implementation and bug fixes. The developer's role shifts toward specifying intent, reviewing AI-generated code, and making architectural decisions rather than typing every line manually.
Microsoft and GitHub are collaborating on "scalar" (a suite of Git performance improvements for large repositories), partial clone, and packfile improvements that make repositories with millions of files and decades of history practical for everyday use. By 2027, repositories the size of Windows (which Microsoft manages in Git) will be routine for enterprise users without specialized infrastructure.
GitHub's Merge Queue feature (stable in 2023, widely adopted by 2026) addresses a classic CI problem: "it works in isolation but breaks after merge." Merge Queue batches multiple approved PRs together, tests them in combination, and only merges them if they pass as a group. By 2027, Merge Queue with configurable batching strategies will be standard practice for high-traffic repositories with active teams.
🔮 2027 Outlook
Key trends to watch: SHA-256 becoming the default for new Git repositories; AI coding assistants generating more code than developers write manually; GitHub Codespaces becoming the primary development environment for many teams; Merge Queue adoption becoming standard for continuous deployment; and GitHub Actions marketplace expanding to cover nearly every CI/CD use case natively.
Git and GitHub proficiency are baseline requirements for virtually every software engineering role in 2026. Whether you are applying for a junior developer position, a senior engineering role, a DevOps engineer position, or a technical lead role, interviewers assume that you know Git well. This section guides you on building Git expertise that stands out.
| Level | Expected Git/GitHub Knowledge | | --- | --- | | Junior | init/clone/add/commit/push/pull, basic branching, PR creation, resolving simple merge conflicts, .gitignore | | Mid-level | Advanced branching strategies, rebase/squash, interactive rebase, git stash, GitHub Actions basics, branch protection rules, Conventional Commits | | Senior | Git internals, advanced workflow design, monorepo strategies, GitHub Actions advanced patterns, security practices, Dependabot, CODEOWNERS, team process design | | DevOps/SRE | All of the above + advanced Actions, environment management, secrets management, self-hosted runners, compliance and audit workflows, IaC with Git |
| Resource | Type | Best For | | --- | --- | --- | | Pro Git (git-scm.com/book) | Free book | Comprehensive Git reference - read it cover to cover | | GitHub Docs (docs.github.com) | Official docs | GitHub features - always up to date | | learngitbranching.js.org | Interactive game | Visual branching and rebasing practice | | GitHub Skills (skills.github.com) | Interactive courses | Hands-on GitHub feature learning | | Oh Shit, Git! (ohshitgit.com) | Quick reference | Recovery scenarios in plain language | | The Git Parable | Essay | Conceptual understanding of Git's design | | GitHub Blog (github.blog) | Blog | Latest GitHub feature announcements |
Git and GitHub together form the most important platform in modern software development. Git's elegant, distributed design - built on an immutable content-addressed object store, lightweight branches, and powerful history rewriting tools - provides the version control foundation that enables teams of all sizes to work effectively. GitHub's collaboration layer - pull requests, Actions, Copilot, Projects, and Security features - transforms Git repositories into complete software development platforms.
Mastering these tools is not a one-time achievement but an ongoing practice. The commands covered in this guide are the foundation; the workflows and team conventions build on them; and the advanced features - CI/CD with Actions, AI assistance with Copilot, security with Advanced Security - create the complete picture of professional development in 2026. Invest in Git fluency consistently, and you will see returns in productivity, code quality, and career advancement throughout your development career.
Start today: