chore: sync content to repo (#10270)

Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com>
2026-09-24 15:00:31 +08:00 · 2026-09-03 10:32:40 +02:00
parent c985837254
commit 15d1b1c3d8
81 changed files with 81 additions and 81 deletions
@@ -1,5 +1,5 @@
 # --hard
- 
+
 `git reset --hard` moves the branch pointer to a specified commit and resets both the staging area and working directory to match it exactly. Any changes in commits after that point, as well as any uncommitted work, get permanently discarded. This is one of the more destructive Git commands, so it should be used carefully since undone changes can be difficult to recover.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # --soft
- 
+
 `git reset --soft` moves the branch pointer to a specified commit while leaving the staging area and working directory untouched. This means all changes from the undone commits remain staged, ready to be recommitted differently. It's useful for combining multiple commits into one without losing any changes.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Branch Naming
- 
+
 Branch naming conventions give structure to how branches are labeled, often including a prefix like `feature/`, `bugfix/`, or `hotfix/` followed by a short description. Consistent naming makes it easy to identify a branch's purpose at a glance and helps automate workflows that trigger based on branch name patterns. Teams often document their convention in a contributing guide so everyone follows the same format.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Caching Dependencies
- 
+
 Caching dependencies in GitHub Actions stores files like package manager directories between workflow runs, avoiding the need to reinstall them from scratch every time. The `actions/cache` action saves and restores these files based on a key, often derived from a lockfile's hash. This significantly speeds up workflows that install the same dependencies repeatedly across multiple runs.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Clean Git History
- 
+
 A clean Git history means commits are logically organized, well described, and free of unnecessary noise like "fix typo" or "WIP" messages. Techniques like squashing commits, rebasing, and writing clear commit messages all contribute to keeping history readable. A clean history makes it easier to trace when and why a specific change was introduced.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Code Reviews
- 
+
 A code review is the process of examining proposed changes in a pull request before they get merged, checking for bugs, style issues, or design concerns. Reviewers can leave comments on specific lines, approve the changes, or request modifications before approval. Code reviews help catch problems early and share knowledge of the codebase across a team.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Committing Changes
- 
+
 Committing saves a snapshot of the staged changes to the repository's history, along with a message describing what was changed and why. Each commit gets a unique hash that identifies it and allows Git to track the exact state of the project at that point. Commits build the timeline that developers can browse, compare, or revert to later.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Detached HEAD
- 
+
 A detached HEAD state occurs when HEAD points directly to a specific commit instead of a branch, typically after checking out a commit hash or tag. Any new commits made in this state aren't attached to a branch, so they can be lost once another branch is checked out unless a new branch is created to save them. This state is often used to inspect old commits without affecting the current branch.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Documentation
- 
+
 Documentation covers the written materials that explain how a project works, how to use it, and how to contribute to it. This includes README files, wikis, and citation files, all of which help users and contributors understand a repository without needing to read through all the source code. Good documentation is often what determines whether an open source project gets adopted or contributed to.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Fast-Forward vs Non-FF
- 
+
 A fast-forward merge happens when the target branch has no new commits since the feature branch was created, so Git simply moves the branch pointer forward without creating a new commit. A non-fast-forward merge occurs when both branches have diverged, requiring Git to create a dedicated merge commit that ties the two histories together. Developers can force a merge commit even when a fast-forward is possible by using `git merge --no-ff`, which some teams prefer for a clearer history.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Fetch without Merge
- 
+
 `git fetch` downloads new commits, branches, and tags from a remote repository without merging them into the local branch. It updates the remote-tracking branches, like `origin/main`, so the developer can inspect incoming changes before deciding to merge or rebase them. This makes fetch a safer way to check for updates compared to `git pull`, which fetches and merges in one step.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Forking vs Cloning
- 
+
 Forking creates a personal copy of someone else's repository under the user's own GitHub account, allowing changes without affecting the original project. Cloning downloads a copy of a repository, whether it's the original or a fork, to a local machine for editing. Contributors typically fork a repository first, then clone their fork locally, so changes can eventually be proposed back to the original project through a pull request.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # git config
- 
+
 `git config` sets configuration values that control how Git behaves, such as the user's name, email, and default editor. These settings can apply at different levels: system-wide, per user, or per repository. Git attaches this information to every commit, which is why setting a name and email is one of the first steps after installing Git.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # git filter-branch
- 
+
 `git filter-branch` rewrites a large portion of a repository's history, often used to remove sensitive files or restructure the project after the fact. It applies a filter across many or all commits, such as deleting a specific file from every point in history. Because it's slow and error-prone, Git's documentation now recommends the `git filter-repo` tool as a faster, safer alternative for the same kind of history rewriting.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Git hooks
- 
+
 Git hooks are scripts that run automatically at specific points in the Git workflow, such as before a commit or after a push. They live in the `.git/hooks` directory and can be written in any scripting language the system supports. Hooks are commonly used to enforce rules, like running tests before allowing a commit, or triggering actions like deployments after a push.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # git log options
- 
+
 `git log` accepts many options to customize how commit history is displayed, such as `--oneline` for a condensed view or `--graph` to visualize branching and merging. Filters like `--author` or `--since` narrow results to specific contributors or time ranges. These options make it easier to search through large histories for exactly the information needed.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # git push --force
- 
+
 `git push --force` overwrites the remote branch's history with the local branch's history, even if they've diverged. This is necessary after rewriting local commits, like through a rebase, since a normal push would be rejected due to mismatched history. Because it can overwrite others' work on a shared branch, `git push --force-with-lease` is often recommended instead, since it fails if the remote has changes the local branch doesn't know about.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Git Remotes
- 
+
 A remote is a version of a repository hosted somewhere other than the local machine, such as on GitHub. Remotes let developers push their local commits to a shared location and pull down changes made by others. A repository can have multiple remotes, though most projects use a single one, conventionally named `origin`.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # git revert
- 
+
 `git revert` creates a new commit that undoes the changes made by a previous commit, without altering existing history. This makes it a safe way to undo changes on a branch that others have already pulled, since it doesn't rewrite any commits. Running `git revert <commit-hash>` applies the inverse of that commit's changes and prompts for a new commit message.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Git Stash Basics
- 
+
 Git stash temporarily saves uncommitted changes so the working directory can be cleaned without committing incomplete work. The command `git stash` saves the current changes and reverts the working directory to match the last commit, while `git stash pop` restores them later. This is useful when a developer needs to quickly switch branches or pull updates without losing in-progress work.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Git vs Other VCS
- 
+
 Git is a distributed version control system, meaning every developer has a full copy of the project history on their own machine, not just the latest snapshot. Older systems like Subversion (SVN) or CVS are centralized, so they depend on a single server for most operations and require a network connection to commit changes. Git allows commits, branching, and history browsing to happen offline, and syncing with a remote server happens only when pushing or pulling.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Git Worktree
- 
+
 Git worktree allows multiple branches to be checked out simultaneously in separate directories, all linked to the same repository. Running `git worktree add <path> <branch>` creates a new working directory for a specific branch without needing to clone the repository again. This is useful when a developer needs to work on two branches at once, like testing a hotfix while a feature branch remains checked out elsewhere.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Actions
- 
+
 GitHub Actions is a CI/CD platform built into GitHub that automates tasks like testing, building, and deploying code in response to repository events. Workflows are defined in YAML files stored in the `.github/workflows` directory and can run on GitHub-hosted or self-hosted runners. It's widely used to automate everything from running test suites on every pull request to deploying applications after a merge.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub CLI
- 
+
 GitHub CLI, or `gh`, is a command-line tool that lets developers interact with GitHub directly from the terminal instead of the web interface. It supports common tasks like creating repositories, managing issues, and opening pull requests without switching context. Being scriptable also makes it useful for automating GitHub-related tasks in scripts or CI pipelines.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Codespaces
- 
+
 GitHub Codespaces provides a cloud-based development environment that can be launched directly from a repository, complete with a configured editor and terminal. It uses a configuration file, typically a `devcontainer.json`, to define the environment's tools, extensions, and dependencies. This lets developers start coding immediately in a consistent setup without needing to install anything locally.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Discussions
- 
+
 GitHub Discussions is a forum-style feature for conversations that don't fit the structure of an issue, such as general questions, ideas, or announcements. Unlike issues, discussions aren't meant to track specific tasks and can be organized into categories like Q&A or ideas. Maintainers often enable discussions to separate open-ended community conversation from actionable bug reports.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Essentials
- 
+
 GitHub Essentials covers the core features needed to start using GitHub as a collaboration platform on top of Git. This includes creating an account, understanding the interface, setting up a profile, and creating repositories. These basics form the starting point for hosting projects online and working with other developers.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Interface
- 
+
 The GitHub interface is the web-based dashboard used to navigate repositories, pull requests, issues, and account settings. It includes a repository view showing files and commit history, a notifications tab, and organization or team pages for shared projects. Learning the layout helps developers find their way around features like code review, project boards, and settings without confusion.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Organizations
- 
+
 A GitHub organization is a shared account used by companies or groups to manage multiple repositories, members, and teams under one umbrella. It allows centralized billing, permission management, and visibility settings across all repositories owned by the organization. Organizations are commonly used instead of personal accounts when multiple people need structured, ongoing access to a set of projects.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Packages
- 
+
 GitHub Packages is a package hosting service that lets developers publish and manage packages, like npm, Docker, or Maven artifacts, directly within GitHub. It integrates with existing repository permissions, so access to a package can follow the same rules as the repository it's tied to. Teams use it to keep both their code and its published packages within the same platform and permission system.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Projects
- 
+
 GitHub Projects is a built-in project management tool that lets teams organize issues and pull requests into boards, tables, or timelines. It supports custom fields, automation rules, and different views to track work across one or multiple repositories. Teams use it to plan sprints, track progress, and visualize the status of ongoing work without leaving GitHub.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Releases
- 
+
 A GitHub release packages a specific tag along with release notes, binaries, or other downloadable assets. It gives users a clear, versioned snapshot of the project they can download without cloning the entire repository. Releases are commonly used to distribute compiled software, mark milestones, and document what changed between versions.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Security
- 
+
 GitHub Security covers the built-in tools that help identify and fix vulnerabilities in a repository, such as dependency scanning, secret scanning, and code scanning. These features can flag outdated dependencies with known vulnerabilities or detect accidentally committed secrets like API keys. Security features can be enabled from the repository settings and often integrate directly with pull requests to flag issues before they get merged.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Sponsors
- 
+
 GitHub Sponsors lets developers and organizations receive financial support directly from users who want to fund their open source work. Sponsors can choose a one-time or recurring monthly contribution, and maintainers can offer different sponsorship tiers with specific perks. This gives open source maintainers a way to earn income for their work directly through the platform.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # GitHub Wikis
- 
+
 A GitHub wiki is a separate space attached to a repository for writing longer-form documentation, tutorials, or notes that don't belong in the main README. Wikis support Markdown and have their own version history, similar to the main repository. They're often used for detailed guides, FAQs, or design documents that would otherwise clutter the codebase.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Installation and Setup
- 
+
 Installing GitHub CLI involves downloading the `gh` tool through a package manager like Homebrew, apt, or winget, depending on the operating system. After installation, running `gh auth login` connects the tool to a GitHub account through browser or token-based authentication. Once authenticated, `gh` commands can be run from any repository to interact with GitHub directly.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Installing Git Locally
- 
+
 Installing Git locally means setting up the Git command-line tool on a personal machine so it can track and manage code changes. The installation process differs by operating system: Windows users typically download an installer from the official Git website, macOS users can install it through Homebrew or Xcode command line tools, and Linux users install it through their package manager. Once installed, running `git --version` in a terminal confirms the setup worked.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Issue Management
- 
+
 GitHub CLI allows creating, listing, and closing issues directly from the terminal using commands like `gh issue create` and `gh issue list`. Filters can narrow results by label, assignee, or state, similar to searching issues on the website. This makes it possible to triage or manage issues without switching to a browser.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Issues
- 
+
 Issues are used to track bugs, feature requests, or tasks related to a repository. Each issue has a title, description, and optional labels, assignees, and milestones, and it can be commented on to discuss the problem or proposed solution. Issues can be closed manually or automatically when a linked pull request that fixes them gets merged.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Kanban Boards
- 
+
 A Kanban board is a visual layout that organizes tasks into columns representing different stages, such as "To Do," "In Progress," and "Done." Items move across columns as their status changes, giving a clear picture of the team's workflow at a glance. GitHub Projects supports this board view natively, letting issues and pull requests be dragged between columns.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Labelling Issues / PRs
- 
+
 Labels are colored tags applied to issues and pull requests to categorize them by type, priority, or status. Common examples include "bug," "enhancement," or "help wanted," and repositories can define custom labels to match their workflow. Labels make it easier to filter and search through large numbers of issues or pull requests at a glance.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Linear vs Non-Linear
- 
+
 A linear history means commits follow a single, straight sequence with no branching or merging, often achieved through rebasing instead of merging. A non-linear history includes branches that diverge and later merge back together, creating a more complex graph of commits. Teams choose between the two based on whether they prioritize a simple, readable log or a history that reflects exactly how work happened in parallel.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Local vs Global Config
- 
+
 Git configuration can be set at the local level, which applies only to the current repository, or at the global level, which applies to every repository for that user. Local settings are stored inside a repository's `.git/config` file and override global ones when both exist. Global settings live in a file in the user's home directory, and developers typically use them to set default identity information like name and email across all their projects.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Managing Remotes
- 
+
 Managing remotes involves adding, renaming, or removing the remote repositories a local project is connected to. The command `git remote add <name> <url>` links a new remote, `git remote rename` changes its label, and `git remote remove` deletes the connection entirely. Running `git remote -v` lists all configured remotes along with their URLs.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Managing Tags
- 
+
 Managing tags involves creating, listing, and deleting tags within a repository. The command `git tag <name>` creates a lightweight tag, while `git tag -a <name> -m "message"` creates an annotated one with extra details. Running `git tag` alone lists existing tags, and `git tag -d <name>` deletes one locally.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Markdown
- 
+
 Markdown is a lightweight markup language used to format text with plain, readable syntax, like using asterisks for bold or a hash symbol for headings. GitHub renders Markdown automatically in README files, issues, pull requests, and comments, converting the plain text syntax into styled output. Its simplicity makes it a common choice for documentation across many platforms beyond just GitHub.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Marketplace Actions
- 
+
 Marketplace Actions are pre-built, reusable workflow steps published by GitHub and the community that can be added to any workflow. Instead of writing custom scripts for common tasks like checking out code or setting up a programming language, a workflow can reference an action like `actions/checkout` or `actions/setup-node`. Using marketplace actions saves time and lets workflows benefit from tools maintained and tested by others.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Merge Strategies
- 
+
 Merge strategies are the different approaches Git offers for combining changes from one branch into another. Options include a standard merge that preserves full history, a squash merge that condenses all commits into one, and a rebase that replays commits on top of another branch. Choosing a strategy affects how clean or detailed the resulting commit history looks.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # PR from a Fork
- 
+
 A pull request from a fork lets a contributor propose changes to a repository they don't have write access to. The contributor forks the repository, makes changes on their own copy, and opens a pull request comparing their fork's branch against the original repository. This workflow is the standard way open source contributions happen, since it doesn't require granting outside contributors direct write access.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # PR Guidelines
- 
+
 Pull request guidelines are the conventions a project sets for how contributions should be submitted, often documented in a `CONTRIBUTING.md` file. They typically cover expectations like keeping pull requests focused on a single change, writing a clear description, and linking related issues. Following these guidelines makes it easier for maintainers to review and merge contributions quickly.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # pre-commit
- 
+
 The `pre-commit` hook runs before a commit is finalized, giving a chance to inspect the staged changes and abort the commit if something is wrong. It's frequently used to run linters, formatters, or tests against the code being committed. If the hook script exits with a non-zero status, the commit is stopped.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # pre-push
- 
+
 The `pre-push` hook runs before commits are pushed to a remote repository, allowing checks to run on the commits about to be shared. It's often used to run a test suite or verify that the branch is up to date before allowing the push to proceed. If the script exits with a non-zero status, the push is cancelled.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Private vs Public
- 
+
 A public repository is visible to anyone on GitHub and can be cloned or viewed by other users, while a private repository restricts access to the owner and any collaborators explicitly invited. Public repositories are common for open source projects that want community contributions, while private repositories suit proprietary code or work in progress. Repository visibility can be changed later in the settings, though switching a private repo to public exposes its entire history.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Profile Readme
- 
+
 A profile README is a special repository named after a GitHub username that displays custom content directly on the user's profile page. It uses standard Markdown, so developers can add text, images, badges, and links to showcase skills, projects, or contact information. GitHub automatically detects this repository and renders its README on the profile instead of requiring a separate page.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Project Planning
- 
+
 Project planning in GitHub Projects involves setting up boards, defining custom fields, and organizing tasks into a workflow that reflects how a team operates. This can include setting milestones, prioritizing issues, and assigning work to specific people or iterations. Planning ahead of time in a project board helps teams track progress and spot bottlenecks before deadlines.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Project Readme
- 
+
 A README is the first file most people see when visiting a repository, typically explaining what the project does, how to install it, and how to use it. It's written in Markdown and rendered automatically on the repository's main page. A good README often includes usage examples, setup instructions, and links to further documentation or contribution guidelines.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Pull Requests
- 
+
 GitHub CLI supports the full pull request workflow from the terminal, including creating one with `gh pr create`, reviewing changes with `gh pr diff`, and merging with `gh pr merge`. This lets developers open and manage pull requests without leaving their code editor or terminal session. It's especially useful for quickly checking pull request status during a coding session.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Repository management
- 
+
 GitHub CLI supports repository management commands like `gh repo create`, `gh repo clone`, and `gh repo view`, letting developers manage repositories without leaving the terminal. These commands mirror actions normally done through the GitHub website, such as creating a new repo or checking its details. This is especially useful for developers who prefer staying in the command line during their workflow.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Rewriting History
- 
+
 Rewriting history refers to Git operations that change existing commits rather than adding new ones on top, such as amending a commit message or rebasing a series of commits. These operations alter commit hashes, which can cause issues for anyone who already has a copy of the original history. Because of this, rewriting history is generally safe on local or unshared branches, but risky on branches others are actively using.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Saved Replies
- 
+
 Saved replies let users store commonly used comment templates that can be inserted into issues or pull requests with a click. This is useful for repetitive responses, like closing an issue with a standard message or thanking a contributor for their submission. GitHub provides some default saved replies, and users can add their own from the settings page.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Scheduled Workflows
- 
+
 Scheduled workflows run automatically at specified times using cron syntax under the `schedule` trigger in a workflow file. This is useful for recurring tasks like nightly builds, periodic cleanup jobs, or fetching data on a regular interval. GitHub runs scheduled workflows based on UTC time, and there can be a slight delay depending on runner availability.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Secrets and Env Vars
- 
+
 Secrets store sensitive values like API keys or passwords securely, configured in a repository's settings and referenced in workflows without exposing their actual values in logs. Environment variables, defined with the `env` key, hold configuration values that steps in a workflow can access during execution. Both are commonly used together, keeping sensitive data out of the workflow file itself while still making it available where needed.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Setting up Profile
- 
+
 Setting up a GitHub profile involves adding a profile picture, bio, location, and links to personal or professional sites. A well-configured profile helps other developers and potential employers understand who is behind the code. GitHub also lets users pin favorite repositories to the profile page to highlight specific projects.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Staging Area
- 
+
 The staging area, also called the index, is where changes are prepared before being committed. Running `git add` moves specific changes from the working directory into the staging area, letting developers choose exactly what to include in the next commit. This separation gives control over grouping related changes together instead of committing every modified file at once.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Storing Artifacts
- 
+
 Artifacts are files produced during a workflow run, like build outputs or test reports, that can be saved and downloaded after the workflow finishes. The `actions/upload-artifact` action stores these files, and `actions/download-artifact` retrieves them in a later job or for manual inspection. Artifacts are commonly used to pass build outputs between jobs or to keep logs and reports for review.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Submodules
- 
+
 A submodule is a Git repository embedded inside another repository as a subdirectory, keeping its own separate history. It allows a project to include and track a specific version of another project without merging their codebases together. Submodules are commonly used for shared libraries or dependencies that are maintained in their own repository.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Tagging
- 
+
 Tagging marks a specific commit as significant, typically used to denote release versions like `v1.0.0`. Unlike branches, tags don't move as new commits are added, so they act as a fixed reference point in history. Tags can be lightweight, just a name pointing to a commit, or annotated, storing extra metadata like the tagger's name and a message.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Teams within Organization
- 
+
 Teams within a GitHub organization group members together to manage permissions more efficiently across multiple repositories. Instead of granting access to each person individually, an admin assigns access to a team, and every member inherits those permissions. This structure is useful for larger organizations where different teams, like frontend or backend developers, need different levels of access to specific repositories.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Undoing Changes
- 
+
 Undoing changes in Git covers the different ways to reverse modifications, whether they're uncommitted, staged, or already committed. Depending on the situation, developers might use `git checkout` to discard local edits, `git reset` to unstage or remove commits, or `git revert` to safely undo a commit that's already been shared. Choosing the right method depends on whether the change has been pushed to a shared remote.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Use in Automation
- 
+
 GitHub CLI can be used inside scripts or CI/CD pipelines to automate tasks like creating releases, commenting on issues, or triggering workflows. Because it supports authentication via tokens, it can run in non-interactive environments without manual login. This makes it a common tool for building custom automation around GitHub's platform without relying on the REST API directly.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Usecases
- 
+
 Common use cases for GitHub Actions include running automated tests on every pull request, building and deploying applications, publishing packages, and sending notifications. It can also automate repository maintenance tasks, like labeling issues or closing stale pull requests. Because workflows can be triggered by nearly any GitHub event, teams use Actions to automate a wide range of development and operations tasks.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Viewing Commit History
- 
+
 Viewing commit history shows the sequence of commits made to a repository, typically through the `git log` command. Each entry includes the commit hash, author, date, and message, giving a record of how the project evolved. Developers use this history to understand past changes, find when a bug was introduced, or review someone else's work.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # What and Why use?
- 
+
 Submodules let a project reference another Git repository at a specific commit, rather than copying its code directly into the main project. This is useful when multiple projects depend on the same shared library and need to track updates to it independently. Using a submodule keeps the dependency's history separate while still linking it to a fixed point in the parent project.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # What and Why?
- 
+
 Git hooks let developers automate tasks or enforce rules at key points in the Git workflow, such as validating a commit message or running a linter before code gets committed. They exist because manually remembering to run checks before every commit or push is error-prone and easy to skip. By automating these checks, hooks help maintain consistency and catch problems earlier in the development process.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # What are these?
- 
+
 GitHub Actions lets developers automate tasks that happen in response to events in a repository, such as pushing code or opening a pull request. Instead of manually running tests or deployments, a workflow file defines what should happen automatically when a specific trigger occurs. This removes repetitive manual steps from a development process and ensures checks run consistently every time.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # What is Version Control?
- 
+
 Version control is a system that tracks changes to files over time, so developers can see who changed what and revert to earlier versions when needed. It keeps a history of every modification, letting multiple people work on the same project without overwriting each other's work. Teams use it to collaborate safely, experiment with new features in isolation, and recover from mistakes.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Why use Version Control?
- 
+
 Version control lets developers track every change made to a codebase and roll back to a previous state if something breaks. It removes the need for manual backups like renamed folders or zipped copies of a project. Multiple people can work on the same files at once without losing each other's changes, and every change is documented with a message explaining why it was made.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Workflow Status
- 
+
 Workflow status indicates whether a GitHub Actions run succeeded, failed, or is still in progress, shown directly on commits, pull requests, and the Actions tab. Status checks can be configured as required, blocking a pull request from merging until the workflow passes. This gives immediate visibility into whether changes broke any automated checks before they get merged.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Working Directory
- 
+
 The working directory is the actual folder on disk where a developer edits files. It reflects the current state of the project, including any changes that have not yet been staged or committed. Git compares the working directory against the staging area and the last commit to determine what has changed.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # Working in a Team
- 
+
 Working in a team on GitHub involves managing shared access, roles, and communication across multiple contributors on the same project. This includes adding collaborators or members, organizing people into GitHub organizations, and structuring them into teams with specific permissions. These features scale collaboration beyond a single developer to groups working together on shared codebases.

 Visit the following resources to learn more:
@@ -1,5 +1,5 @@
 # YAML Syntax
- 
+
 GitHub Actions workflows are written in YAML, a human-readable format that uses indentation to represent structure instead of brackets or tags. A workflow file defines keys like `on` for triggers, `jobs` for the tasks to run, and `steps` for individual commands within each job. Getting the indentation right is important, since YAML is sensitive to spacing and incorrect indentation can break the entire workflow.

 Visit the following resources to learn more: