Git Github
Lộ trình phát triển toàn diện Git Github theo tiêu chuẩn quốc tế nilbuild/developer-roadmap
Hướng dẫn từng bước từ nền tảng đến chuyên sâu giúp bạn làm chủ Git Github. Tích hợp tài liệu lý thuyết, bài viết thực chiến, video tham khảo và bài tập lập trình trực tiếp trên IDE.
Nền Tảng & Khái Niệm Cốt Lõi
Giai đoạn 1 tập trung hoàn thiện 31 chủ đề then chốt.
--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.
--mixed
When using mixed mode, the HEAD pointer is moved to the specified commit. However, files in your working directory remain as they were before the reset. The staging area (index) is updated to match the specified commit.
--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.
Adding / Updating
To add a submodule to a repository, use `git submodule add https://github.com/user/submodule-repo.git`, which is the typical format for specifying the URL of the submodule repository. This creates a new folder for the submodule and checks it out at the specified revision. To update an existing submodule to its latest commit, run `git submodule update`. If you want to pull in changes from upstream while keeping your submodule's history intact, use `git submodule sync` followed by `git submodule update`.
Automations
To add automation to your GitHub project, use built-in workflows that can trigger actions such as setting fields on item changes or archiving items meeting specific criteria, and also configure automatic item addition from repositories based on matching criteria.
Between Branches
When comparing the differences between two branches, such as a feature branch and its upstream parent branch, use `git diff <branch1>..<branch2>`. This command displays the changes made on the feature branch relative to the parent branch. It's useful for reviewing the impact of new features or changes before merging them into your mainline.
Between Commits
To compare two specific commits in your Git history, use git diff followed by the hashes of the commits. This will show you the changes made between those two points, including added, modified, and deleted lines.
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.
Branching Basics
Branches in Git serve as separate lines of development that allow multiple features or changes to be worked on simultaneously without affecting the main codebase. With branches, you can create isolated environments for different tasks, collaborate with others, and manage complex workflows.
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.
Campus Program
The GitHub Campus Program offers GitHub Enterprise Cloud and GitHub Enterprise Server free-of-charge for schools that want to make the most of GitHub for their community. This program provides access to a comprehensive set of developer tools, as well as resources and support to help students and educators build projects, collaborate, and develop skills in software development.
Checkout Branch
In Git, to "checkout" from a branch means to switch your working directory to that branch, making it the active branch. This updates your files to match the state of that branch and allows you to work on it.
Checkout Tags
Tags in Git are typically used to mark specific points in history, such as a release version. Checking out a tag means switching your working directory to the state of the repository at the point in time when that tag was created.
Cherry Picking Commits
Cherry-picking in Git allows you to apply a specific commit from one branch to another, without merging the entire branch. This is useful when you want to bring in a specific feature or fix from one branch to another without incorporating all the changes from the source branch.
CITATION files
You can add a CITATION.cff file to the root of a repository to let others know how you would like them to cite your work. The citation file format is plain text with human- and machine-readable citation information.
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.
Client vs Server Hooks
Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits.
Cloning Repositories
Cloning a repository in Git and GitHub involves creating a local copy of a remote repository on your computer. This allows you to work on the project locally, commit changes, and later push those changes back to the remote repository.
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.
Collaboration on GitHub
Collaboration on GitHub is a powerful way for multiple people to work together on the same project, using Git as the version control system. GitHub provides various tools and workflows that make collaboration efficient and organized.
Collaborators / Members
In GitHub, collaborators and members refer to individuals who contribute to or have access to your repository. Collaborators are users who have been granted permission to contribute code, make changes, and push updates to your repository, whereas members are the owners of a repository, including organization owners who have full control over their team's repositories. Members can be either individual collaborators or part of an organization team, with varying levels of access and permissions based on their role within the team.
Collaborators
Collaborators in GitHub are users who have been granted direct access to a repository by the repository owner or organization administrators. Collaborators can perform actions like pushing commits, creating branches, and managing issues or pull requests, depending on the permissions granted to them. They are typically added to private repositories or to public repositories where more control over contributions is needed.
Commit Messages
A Git commit message is a brief explanation of the changes introduced in a particular commit. It helps others (and your future self) understand the purpose of the changes and the context behind them. Writing clear and informative commit messages is an important practice for maintaining a well-organized and easily navigable project history.
commit-msg
The commit-msg hook is a client-side hook that runs after you enter a commit message, but before the commit is finalized in your repository. It's typically used to validate or modify the commit message before it's recorded in the Git history.
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.
Contribution Guidelines
Contribution guidelines are essential for collaborative projects on GitHub as they help streamline collaboration, set expectations for contributions, and maintain the project's quality and consistency.
Creating Account
To get started with GitHub, you'll need to create a free personal account on [GitHub.com](http://GitHub.com) and verify your email address. Every person who uses [GitHub.com](http://GitHub.com) signs in to a personal account. Your personal account is your identity on [GitHub.com](http://GitHub.com) and has a username and profile.
Creating Apps
GitHub Apps are a way to integrate with the GitHub platform programmatically, using either the REST API or GraphQL API. They allow developers to create custom integrations that can automate tasks, provide real-time notifications, and build custom workflows.
Creating Branch
Creating a branch in Git is a fundamental part of working with version control, allowing you to work on different features or fixes without affecting the main codebase. You can create branches either through the terminal or github interface
Creating Repositories
Creating a Git repository means setting up a system to track changes in your project's files over time. This is crucial for version control, allowing you to manage, review, and collaborate on code efficiently.
Custom Domains
On GitHub Pages, users can customize their site's URL by connecting a custom domain to their repository. This feature allows users to use their own domain name instead of the default [GitHub.io](http://GitHub.io) subdomain, giving their site a more professional and personalized look.
Kỹ Năng Trọng Tâm & Thực Hành
Giai đoạn 2 tập trung hoàn thiện 31 chủ đề then chốt.
Deleting Branch
Deleting a Git branch means removing a line of development from your Git repository. A branch in Git is essentially a pointer to a specific commit, representing an independent line of development. When you delete a branch, you’re removing this pointer, making that line of development no longer accessible through the branch name.
Deploying Static Websites
Deploying static websites on GitHub Pages involves uploading and serving website content that is generated beforehand, without dynamic functionality. This approach allows for fast deployment, low maintenance, and improved security.
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.
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.
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.
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.
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.
Git Attributes
Git attributes are settings stored in the .gitattributes file, controlling how Git handles files in your repository. They can influence filtering (e.g., ignoring specific files), conversion (formatting or transforming files during Git operations), and formatting (applying consistent styles). These settings can be applied to specific file types (like \*.txt) or filter files based on content patterns. Attributes also define smudge patterns (highlighting differences) and ignore patterns, helping maintain a clean repository by automatically applying intended settings for certain file types.
Git Bisect
Git Bisect is an interactive tool used to identify which commit in your project's history introduced a bug or regression. You start by identifying two commits: one where the issue isn't present (the "good" commit) and another where it is (the "bad" commit). Then, run `git bisect start`, followed by `git bisect good` for the good commit and `git bisect bad` for the bad commit. Git Bisect will guide you through a binary search process, asking you to test the midpoint of your current range until it identifies the exact commit that introduced the bug or regression.
git commit --amend
`git commit --amend` is a command used to modify the most recent commit in your repository's history by updating its message, adding or removing files, or changing the commit's metadata. This allows you to correct mistakes or improve the commit's description after it has been made. When using --amend, Git will replace the existing commit with a new one that includes any changes made since the last commit, effectively "amending" the previous commit.
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.
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.
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.
git init
The `git init` command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new, empty repository. Most other Git commands are not available outside of an initialized repository, so this is usually the first command you'll run in a new project.
Git LFS
Git Large File Storage (LFS) is an extension that helps manage large files by tracking metadata, not storing entire files. It allows storing and tracking binary assets like images, videos, audio files separately from your regular Git repository. By storing only metadata in your Git repository, you improve clone and push times, reducing storage usage. This approach is particularly useful for media repositories, large dataset storage, and binary asset management in game development. Note that Git LFS requires a separate server or storage system to store actual file content.
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.
Git Patch
In Git, a patch is a file that contains a set of changes made to a project's codebase. It's essentially a diff (difference) file that shows the modifications between two versions of a commit or a branch. However, despite its usefulness in certain contexts, the use of Git patches has declined somewhat with the advent of more modern and efficient ways to manage code changes.
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.
git rebase
Git rebase is a powerful command in Git that allows you to integrate changes from one branch into another. Unlike git merge, which creates a new commit to combine the histories of two branches, git rebase moves or applies commits from one branch on top of another, effectively re-writing the commit history.
Git Reflog
Git reflog is a powerful tool in Git that keeps a record of all the changes made to the branches and commits in your repository, including actions that are not part of the regular commit history, such as resetting branches or checking out commits. It's particularly useful for recovering lost commits or understanding the history of changes in your repository, even if those changes are not reflected in the normal commit history.Reflog stands for "reference log." It records when the tip of branches or other references (like HEAD) is updated in your repository.
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`.
git reset
Git reset is a command that allows you to "undo" or reset your current branch to a previous state by moving its HEAD pointer, effectively discarding changes made since then. When using git reset, it's essential to specify one of the three modes: soft, hard, or mixed. The mode you choose will determine how Git interacts with files in your working directory and staging area.
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.
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.
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.
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.
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.
GitHub API
The GitHub API is a powerful tool that allows developers to interact with the GitHub platform programmatically. It provides access to various GitHub features, such as user data, repository information, and commit history, through both REST and GraphQL interfaces. The API supports authentication, implements rate limiting, and offers webhooks for real-time notifications, enabling developers to automate tasks, create custom integrations, and build applications that leverage GitHub's functionality.
GitHub Apps
A GitHub App is a way to integrate with the GitHub platform programmatically, using either the REST API or GraphQL API. It allows developers to create custom integrations that can automate tasks, provide real-time notifications, and build custom workflows.
GitHub Classroom
GitHub Classroom is an integrated feature within GitHub that allows educators to create and assign homework assignments, projects, or quizzes directly to students. This feature streamlines the process of teaching and learning by making it easy for instructors to share code, provide feedback, and track student progress all in one place. By using GitHub Classroom, teachers can focus on high-level instruction and student engagement, while also promoting collaboration and hands-on learning experiences.
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.
Kiến Trúc Nâng Cao & Tối Ưu
Giai đoạn 3 tập trung hoàn thiện 31 chủ đề then chốt.
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.
GitHub Copilot
GitHub Copilot is an AI-powered code-completion tool that helps developers write code faster and with less errors. It uses a combination of machine learning algorithms and access to GitHub's vast repository of open-source code to provide context-aware suggestions for coding tasks. Copilot can generate entire functions, methods, or even entire classes based on the context of the code being written. This feature aims to reduce the time spent on coding by providing immediate and relevant suggestions, allowing developers to focus more on high-level design and problem-solving.
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.
GitHub Education
GitHub Education is a program that provides free and discounted access to GitHub's developer tools, services, and resources for students, teachers, and researchers. This program aims to support education and research in software development, by making it easier for students and educators to learn, collaborate, and build projects on GitHub. By using GitHub Education, students can gain hands-on experience with real-world coding challenges, while educators can create a more engaging and interactive learning environment.
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.
GitHub Gists
A GitHub Gist is a small code or text snippet that can be shared with others. It is a simple way to share code, configuration files, or other snippets of text without creating a full-fledged repository. Gists are useful for sharing examples, demos, or tutorials, and they can also serve as a starting point for larger projects. Each gist has a unique URL that can be shared with others, allowing them to view and edit the content. Gists support various file types, including code files, text files, and even images. They also provide features like syntax highlighting, line numbers, and commit history.
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.
GitHub Marketplace
GitHub Marketplace is a platform that allows developers to discover, install, and manage third-party tools and services directly within their GitHub environment. These tools can provide a range of features, such as code analysis, project management, or collaboration, making it easier for developers to work efficiently and effectively. By using the GitHub Marketplace, developers can streamline their workflow, reduce friction, and focus on writing code.
GitHub Models
GitHub Models is a feature that allows developers to search, explore, and use pre-trained AI models from various sources. This platform provides a way to discover and experiment with these models, making it easier to integrate AI capabilities into software projects. By using GitHub Models, developers can quickly find and try out different models, without having to train them from scratch.
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.
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.
GitHub Pages
GitHub Pages is a feature that allows users to host and publish web content directly from their GitHub repositories. It provides a simple way to create and deploy websites, blogs, or projects without the need for manual configuration or maintenance. Users can upload custom themes, add plugins, and use various tools to customize their pages.
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.
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.
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.
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.
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.
.gitignore
Ignored files are tracked in a special file named `.gitignore` that is checked in at the root of your repository. There is no explicit git ignore command: instead the `.gitignore` file must be edited and committed by hand when you have new files that you wish to ignore. `.gitignore` files contain patterns that are matched against file names in your repository to determine whether or not they should be ignored.
GraphQL API
The GitHub GraphQL API is a set of APIs that provides access to various GitHub features, such as user data, repository information, and commit history. It allows developers to interact with the GitHub platform programmatically using GraphQL queries.
Handling Conflicts
When multiple developers work on the same project simultaneously, conflicts can arise during the merging process. This occurs when changes made by different individuals overlap or contradict each other in a specific code file. In such situations, Git's conflict resolution mechanism comes into play, allowing users to manually resolve these issues and merge the conflicting changes.
HEAD
The `HEAD` file is at the core of how Git knows the SHA-1 of the last commit when running commands like `git branch <branch>`. It serves as a symbolic reference, pointing to the current branch. However, in rare cases, HEAD can contain the actual SHA-1 value of a Git object, such as when checking out a tag, commit, or remote branch, which puts your repository in a "detached HEAD" state.
History
The history of a Git repository is a record of all commits made over time, including changes to files, commit messages, and metadata. This history is stored as a series of snapshots, with each commit representing a new version of the codebase.
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.
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.
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.
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.
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.
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.
Learn the Basics
A Version Control System (VCS) is a tool that helps developers manage changes to their code over time. It allows multiple versions of a project to exist simultaneously, making it easier to collaborate with others and maintain a record of all modifications.
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.
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.
Hệ Sinh Thái & Triển Khai Thực Tế
Giai đoạn 4 tập trung hoàn thiện 31 chủ đề then chốt.
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.
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.
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.
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.
Mentions
Mentions on GitHub allow you to notify specific users or teams about comments, issues, pull requests, or other activities. This feature improves collaboration by encouraging participation and discussion among team members, increasing visibility of important topics, and streamlining communication within your repository. To use mentions, simply type `@username` or `@teamname` in a comment, and GitHub will auto-complete the mention as you type, automatically linking their username to the comment and notifying them about the discussion.
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.
Merging Basics
A merge in Git is the process of combining changes from one branch into another. When you want to integrate updates from one branch (the source) into another branch (the target), you need to perform a merge. This involves resolving conflicts between the two branches, if any exist. The goal of merging is to create a new commit that represents the combined changes from both branches, resulting in a single, cohesive history for your project.
OAuth Apps
GitHub OAuth Apps allow developers to integrate with GitHub using OAuth 2.0 authentication. They enable secure, token-based access to specific GitHub resources like repositories, issues, and pull requests. OAuth Apps can automate tasks, personalize interactions, and provide real-time notifications through webhooks, all while allowing users to approve only the necessary permissions without sharing their credentials.
post-checkout
Git post-checkout hooks are scripts that run automatically after a successful `git checkout` operation. These hooks provide a way to customize Git's behavior and perform specific actions when switching branches or updating the working directory. Post-checkout hooks can be used for tasks such as updating dependencies, regenerating files, or adjusting project settings based on the newly checked-out branch. They offer developers a powerful tool to automate workflows and maintain consistency across different branches in a Git repository.
post-update
Git post-update hooks are scripts that run automatically after a successful push to a repository. These hooks are executed on the remote repository and are typically used for server-side tasks such as updating other services, triggering continuous integration processes, or notifying team members about changes. Post-update hooks provide a powerful mechanism for automating workflows and maintaining consistency across different parts of a project's infrastructure, making them an essential tool for streamlining development processes and enhancing collaboration in Git-based projects.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Pull Requests
A pull request is a proposal to merge a set of changes from one branch into another. In a pull request, collaborators can review and discuss the proposed set of changes before they integrate the changes into the main codebase. Pull requests display the differences, or diffs, between the content in the source branch and the content in the target branch.
Pushing / Pulling Changes
When you pull changes in Git, you're fetching and integrating changes from a remote repository into your local repository. This operation updates your local branch with the latest changes from the remote branch. Whereas When you push changes in Git, you're sending your local commits to a remote repository, such as GitHub, GitLab, or Bitbucket. This operation updates the remote repository with your latest changes.
Pushing Tags
Pushing tags in Git is the process of sharing your local tags with a remote repository. Tags in Git are used to mark specific points in the repository's history, typically to signify a release or a milestone.
Reactions
Reactions in GitHub are a way for users to express their feelings or opinions about issues, pull requests, comments, and other discussions without adding additional comments. They are similar to "likes" or "emojis" on social media platforms, providing a quick and non-verbal way to engage with content.
Rebase
Rebasing in Git is a powerful and potentially complex feature used to reorganize or modify a series of commits. The primary purpose of rebasing is to create a cleaner, more linear project history by moving or combining changes from one branch into another.
Renaming Branch
Renaming a branch in Git means changing the name of a branch to something different while preserving its history and the commits it contains. The branch itself remains the same in terms of the code and history it tracks, but the reference (the name by which you refer to it) is updated
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.
REST API
The GitHub REST API is a set of APIs that provide access to various GitHub features, such as user data, repository information, and commit history. It allows developers to interact with the GitHub platform programmatically.
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.
Roadmaps
GitHub Roadmaps are a feature that helps you visualize and organize plans for your projects, allowing you to create a high-level view of milestones and goals, and collaborate on planning and tracking progress with team members.
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.
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.
Chuyên Gia & Mở Rộng Hệ Thống
Giai đoạn 5 tập trung hoàn thiện 31 chủ đề then chốt.
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.
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.
Squash
Squashing in Git, refers to the process of combining multiple commits into a single commit. This is often done to create a cleaner and more concise commit history, especially before merging a feature branch into the main branch.
Staged Changes
To view the changes you've staged with `git add`, but not yet committed, use `git diff --cached`. This command compares the staged files against their original versions in the repository. It's a quick way to review what you're about to commit before finalizing it.
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.
Static Site Generators
GitHub offers a set of static site generators (SSGs) that allow users to create and deploy websites directly from their GitHub repositories. These SSGs include `Jekyll`, `Hugo`, and `Middleman`, among others. They provide a simple way to build websites without the need for manual configuration or maintenance.
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.
Student Developer Pack
The GitHub Student Developer Pack is a collection of developer tools and resources that are offered free or at a discounted price to students through the GitHub Education program. This pack includes access to GitHub, GitHub Desktop, GitHub Classroom, GitHub Student Developer Kit, and other benefits. By using the Student Developer Pack, students can gain hands-on experience with professional developer tools, while also getting access to a wide range of educational resources.
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.
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.
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.
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.
Unstaged Changes
For changes that are not yet staged with `git add`, such as untracked new files or modified existing ones , use `git diff`. This command compares your working directory (your current changes) against the staging area (changes already staged with `git add`). It’s a useful tool for reviewing local modifications before deciding whether to stage them for future commits.
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.
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.
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.
Viewing Diffs
Viewing diffs in Git is crucial for understanding the changes made to your code. This is especially important when collaborating with others or reviewing your own work over time. Diffs show you exactly what lines have been added, modified, or removed between different versions of your files. This feature helps in code review processes, troubleshooting issues, and maintaining a clear history of your project's evolution. Git provides various commands and tools to view these differences, making it easier to track and manage changes effectively.
Webhooks
GitHub Webhooks allow developers to receive real-time notifications about events happening within their repository, such as commits, pull requests, and issues. These webhooks enable users to automate tasks, integrate with other services, and build custom workflows.
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.
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.
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.
What is a Repository
A repository is a storage location for your project's code, documentation, and other files. It serves as a central hub for collaboration, version control, and code management. It allows multiple people to work on the same project without overwriting each other's work.
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.
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.
Workflow Context
Workflow context in GitHub Actions refers to the environment and variables that are available to a workflow. It includes information about the workflow's execution, such as the event that triggered it, the repository, and the workflow itself.
Workflow Runners
Workflow runners are the environments where GitHub Actions workflows are executed. They are hosted on GitHub-hosted virtual machines (GHVMs) or self-hosted runners. Each runner has a specific configuration and capabilities, depending on its type.
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.
Workflow Triggers
Workflow triggers are events that initiate a GitHub Actions workflow. They can be scheduled, triggered by code changes, or manually initiated. This allows for automation of tasks based on specific conditions.
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.
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.
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.