Add content to git/github roadmap (up to git-worktree) (#6587)
* Add content to git/github roadmap (up to git-worktree) * Apply suggestions from code review add links to topics with no links. --------- Co-authored-by: dsh <daniel.s.holdsworth@gmail.com>pull/6602/head
Stavros Siamantas
4 months ago
committed by
GitHub
parent
9d8c7f7253
commit
0d5355018b
54 changed files with 318 additions and 72 deletions
@ -1 +1,7 @@ |
||||
# --hard |
||||
|
||||
With this option, both the HEAD pointer and the working directory's contents are updated to match the specified commit. Any changes made since then will be lost. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@--hard documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---hard) |
||||
@ -1 +1,5 @@ |
||||
# --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. |
||||
|
||||
- [@official@--mixed documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---hard) |
||||
@ -1 +1,5 @@ |
||||
# --soft |
||||
|
||||
In this mode, only the HEAD pointer is moved to the specified commit. The files in your working directory are not modified, but they remain as they were when you started the reset. |
||||
|
||||
- [@official@--soft documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---hard) |
||||
@ -1 +1,8 @@ |
||||
# 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`. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git submodules](https://www.atlassian.com/git/tutorials/git-submodule) |
||||
- [@article@Working with submodules](https://github.blog/open-source/git/working-with-submodules/) |
||||
@ -1 +1,8 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Automating your project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project) |
||||
- [@video@GitHub Project Management - Create GitHub Project Board & Automations](https://www.youtube.com/watch?v=oPQgFxHcjAw&t=600s) |
||||
@ -1 +1,6 @@ |
||||
# 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. |
||||
|
||||
- [@article@How to compare branches in Git diff](https://scribehow.com/shared/How_to_Compare_Branches_in_GitHub__xsotezV-S1O-GL0PquqJwQ) |
||||
- [@article@How can I see the differences between two branches?](https://stackoverflow.com/questions/9834689/how-can-i-see-the-differences-between-two-branches) |
||||
@ -1 +1,6 @@ |
||||
# 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. |
||||
|
||||
- [@article@Comparing changes with Git diff](https://refine.dev/blog/git-diff-command/) |
||||
- [@video@Git Diff 2 Different Commits, Tags or Branches](https://www.youtube.com/watch?v=uq5VWPDCtFo) |
||||
@ -1 +1,8 @@ |
||||
# Branch Naming |
||||
|
||||
A well-defined branch naming convention is essential for maintaining a clean and organized Git workflow. It's recommended to use descriptive and meaningful names that clearly indicate the purpose of each branch. For example, using prefixes like `feature/`, `fix/`, or `docs/` can help identify whether a branch is related to new feature development, bug fixes, or documentation updates. Additionally, including the issue or task ID (e.g., `issue/123`) can provide context and make it easier for team members to find relevant information. By following a consistent naming convention, you can improve collaboration, reduce confusion, and increase the overall efficiency of your Git workflow. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Naming conventions for Git Branches — a Cheatsheet](https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534) |
||||
- [@article@Git Branching Naming Convention: Best Practices to Follow](https://phoenixnap.com/kb/git-branch-name-convention) |
||||
@ -1 +1,8 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) |
||||
- [@video@Git Branches Tutorial](https://www.youtube.com/watch?v=e2IbNHi4uCI) |
||||
@ -1 +1,13 @@ |
||||
# Caching Dependencies |
||||
|
||||
GitHub Actions provides a caching feature that allows you to store and reuse dependencies between workflows, reducing the time it takes to run your actions. By caching dependencies, you can: |
||||
- Reuse compiled code |
||||
- Store database connections |
||||
- Reduce network traffic |
||||
|
||||
It is highly recommended to not store any sensitive information in the cache. For example, sensitive information can include access tokens or login credentials stored in a file in the cache path. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Caching dependencies to speed up workflows](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows) |
||||
- [@video@Cache Management with GitHub actions](https://www.youtube.com/watch?v=7PVUjRXUY0o) |
||||
@ -1 +1,6 @@ |
||||
# 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. |
||||
|
||||
- [@article@Inviting collaborators to a personal repository](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository) |
||||
-[@official@REST API endpoints for collaborators](https://docs.github.com/en/rest/collaborators/collaborators?apiVersion=2022-11-28) |
||||
|
||||
@ -1 +1,8 @@ |
||||
# commit-msg |
||||
|
||||
The commit-msg hook is a client-side hook that runs after you've committed changes to your repository. It's typically used to validate or modify the commit message before it's recorded in the Git history. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@A Git-Hook for Commit Messages Validation - No Husky, Just JS](https://dev.to/mbarzeev/a-git-hook-for-commit-messages-validation-no-husky-just-js-1hni) |
||||
- [@video@Git Hooks Made Easy: Create a Custom 'commit-msg' Hook Script](https://www.youtube.com/watch?v=yH1lBm5t97s) |
||||
@ -1,8 +1,8 @@ |
||||
# Committing Changes |
||||
|
||||
Committing changes in Git is a crucial part of version control, allowing you to save your progress and record a snapshot of your project's current state |
||||
Committing changes in Git is a crucial part of version control, allowing you to save your progress and record a snapshot of your project's current state. |
||||
|
||||
Learn more from the following resources: |
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@How git commit works](https://github.com/git-guides/git-commit) |
||||
- [@article@Git commit](https://www.atlassian.com/git/tutorials/saving-changes/git-commit) |
||||
@ -1,8 +1,7 @@ |
||||
# Creating Account |
||||
|
||||
To get started with GitHub, you'll need to create a free personal account on GitHub.com and verify your email address. |
||||
Every person who uses GitHub.com signs in to a personal account. Your personal account is your identity on GitHub.com and has a username and profile. |
||||
To get started with GitHub, you'll need to create a free personal account on GitHub.com and verify your email address. Every person who uses GitHub.com signs in to a personal account. Your personal account is your identity on GitHub.com and has a username and profile. |
||||
|
||||
Learn more from the following resources: |
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Creating an account on GitHub](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github) |
||||
@ -1 +1,8 @@ |
||||
# Detached HEAD |
||||
|
||||
In Git, a detached head occurs when you check out a commit directly using its hash instead of a branch name. This leaves your repository's HEAD pointer pointing directly at that commit, rather than being linked to a specific branch. To view the history and changes made in a detached head, use `git log` or `git show`. If you want to see the differences between the current detached head and another branch, use `git diff <branch>`. A detached head can be a useful temporary state for exploring specific commits or features, but it's essential to merge those changes back into a branch before sharing them with others. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@How to resolve detached HEAD state in Git](https://graphite.dev/guides/how-to-resolve-detached-head-state-in-git) |
||||
- [@video@Head & Detached Head](https://www.youtube.com/watch?v=HvDjbAa9ZsY) |
||||
@ -1 +1,16 @@ |
||||
# Documentation |
||||
|
||||
A well-maintained repository should include documentation that helps others understand the project, its context, and how to contribute to it. This is essential for fostering a community around your project and making it easier for newcomers to join in. |
||||
|
||||
Here are some key sections of documentation that you should consider including in each repository: |
||||
|
||||
- README.md: A brief introduction to the project, explaining what it's about, why it exists, and how to get started. |
||||
- CONTRIBUTING.md: Guidelines on how others can contribute to the project, including steps for reporting issues, submitting pull requests, or suggesting new features. |
||||
- LICENSE: Information about the license under which the repository is released, ensuring users understand their rights and responsibilities when using your code. |
||||
- CHANGELOG: A history of changes made to the project over time, highlighting significant updates, bug fixes, or feature additions. |
||||
|
||||
These documents help ensure a smooth onboarding process for contributors, making it easier for them to collaborate effectively and enhance the overall project. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@How to Manage Documentation in a GitHub Repository: A Guide for Junior Developers](https://dev.to/mochafreddo/how-to-manage-documentation-in-a-github-repository-a-guide-for-junior-developers-pgo) |
||||
@ -1 +1,9 @@ |
||||
# Fetch without Merge |
||||
|
||||
Running `git fetch` retrieves changes from a remote repository into your local clone, but does not automatically merge any of these changes into your local working directory. This is different from `git pull`, which both fetches and merges remote changes. By using fetch without merge, you can ensure that your local clone is up-to-date with the latest information from the remote repository, while leaving your working directory unchanged. You can then choose to apply these changes by using merge or rebase. This approach helps maintain a clean and consistent local state, making it easier to manage and commit changes. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Fetch](https://git-scm.com/docs/git-fetch) |
||||
- [@article@Git fetch](https://www.atlassian.com/git/tutorials/syncing/git-fetch) |
||||
- [@video@Git Fetch | What is Git Fetch and How to Use it | Learn Git](https://www.youtube.com/watch?v=uEEcw1s_wWk) |
||||
@ -1 +1,9 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Customizing Git - Git Attributes](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes) |
||||
- [@opensource@gitattributes/gitattributes](https://github.com/gitattributes/gitattributes) |
||||
- [@article@The benefits of git attributes and how to set them up](https://medium.com/@cloudwala/the-benefits-of-git-attributes-and-how-to-set-them-up-87f90251b8e0) |
||||
@ -1 +1,9 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Bisect](https://git-scm.com/docs/git-bisect) |
||||
- [@article@Using `git bisect` to find the faulty commit](https://dev.to/alvesjessica/using-git-bisect-to-find-the-faulty-commit-25gf) |
||||
- [@video@Git Bisect | How to use Git Bisect | Learn Git](https://www.youtube.com/watch?v=z-AkSXDqodc) |
||||
@ -1 +1,9 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Changing a commit message](https://docs.github.com/en/enterprise-cloud@latest/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message) |
||||
- [@article@Rewriting history](https://www.atlassian.com/git/tutorials/rewriting-history) |
||||
- [@video@Git Amend Tutorial: Rewrite Git History](https://www.youtube.com/watch?v=q53umU5vMkk) |
||||
@ -1 +1,14 @@ |
||||
# Git hooks |
||||
|
||||
Git hooks are scripts that run automatically at specific points during the Git workflow, such as when you commit, push, or pull changes from a repository. These scripts can be used to perform various tasks, like validating code, formatting files, or even sending notifications. |
||||
|
||||
There are two types of Git hooks: |
||||
|
||||
- Client-side hooks: Run on your local machine before committing changes. |
||||
- Server-side hooks: Run on the remote server when you push changes. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Customizing Git - Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) |
||||
- [@article@Git hooks](https://www.atlassian.com/git/tutorials/git-hooks) |
||||
- [@video@What are GitHooks? Explained in 5 minutes](https://www.youtube.com/watch?v=1OFiiPretCM) |
||||
@ -1 +1,8 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Learning About Git Large File System (LFS)](https://medium.com/swlh/learning-about-git-large-file-system-lfs-72e0c86cfbaf) |
||||
- [@video@Git LFS (Large File Storage) | Learn Git](https://www.youtube.com/watch?v=jXsvFfksvd0) |
||||
@ -1 +1,21 @@ |
||||
# git log options |
||||
|
||||
`git log` is a command in Git that shows the commit history of your repository. It provides a detailed view of all commits, including their hashes, authors, dates, and messages. |
||||
|
||||
Here are some common git log options: |
||||
|
||||
- -2: Only show the last two commits. |
||||
- --all: Show all branches in the repository. |
||||
- --graph: Display the commit history as a graph. |
||||
- --no-color: Disable colorized output. |
||||
- --stat: Show a statistical summary of changes. |
||||
- **-S`: Only show commits with modified files. |
||||
|
||||
You can combine these options to tailor your log output to suit your needs. |
||||
|
||||
For example, `git log -2 --graph` will display the last two commits in graph form. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Log](https://git-scm.com/docs/git-log) |
||||
- [@article@Git Log Cheatsheet](https://elijahmanor.com/blog/git-log) |
||||
@ -1 +1,8 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git Patch](https://www.gitkraken.com/learn/git/git-patch) |
||||
- [@article@How to generate and apply patches with git?](https://gist.github.com/nepsilon/22bc62a23f785716705c) |
||||
@ -1 +1,8 @@ |
||||
# git push --force |
||||
|
||||
`git push --force` is a command that allows you to overwrite or "force" an existing commit on a remote repository with a new commit from your local repository. This can be useful in certain situations, such as when you need to update the remote branch with changes that were previously rejected or when you want to remove commits that are no longer relevant. However, it's essential to exercise caution when using git push --force because it can overwrite changes made by others or even your own previous work. Always verify that there are no conflicting changes on the remote repository before using this command. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git Push Force](https://www.gitkraken.com/learn/git/problems/git-push-force) |
||||
- [@video@How to force push to GitHub?](https://www.youtube.com/watch?v=wgXbfLn-zkI) |
||||
@ -1 +1,8 @@ |
||||
# Git Remotes |
||||
|
||||
In Git, a remote is a reference to a repository that exists on another server or system. Remotes allow you to access and interact with a copy of your repository that is stored elsewhere, making it possible to collaborate with others, share your work, and maintain multiple copies of your repository for backup and disaster recovery purposes. When you add a remote to your local repository, Git creates a reference to the remote repository, enabling you to push changes from your local repository to the remote one, pull changes from the remote to your local one, or fetch changes from the remote without updating your local copy. This enables distributed development and helps maintain a centralized version of your project's history, making it easier to track changes, manage conflicts, and ensure that everyone has access to the most up-to-date code. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@About remote repositories](https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories) |
||||
- [@video@What is a Remote Repository? [Beginner Git Tutorial]](https://www.youtube.com/watch?v=Lb4yvfrX_7I) |
||||
@ -1 +1,8 @@ |
||||
# 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. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git reset](https://www.atlassian.com/git/tutorials/undoing-changes/git-reset) |
||||
- [@video@Git Reset | How to Use Git Reset | Learn Git](https://www.youtube.com/watch?v=s1idhUiCk38) |
||||
@ -1 +1,14 @@ |
||||
# git revert |
||||
|
||||
Git revert is a command that allows you to "undo" or revert specific commits in your Git repository. It creates a new commit that reverses the changes made by the specified commit(s), effectively rolling back your code to a previous state. |
||||
|
||||
Here are some key things to know about `git revert`: |
||||
|
||||
- Reverts changes, not moves HEAD: Unlike `git reset`, which can move your current branch's head to a different point in history, `git revert` creates new commits that reverse the changes made by specific commit(s). |
||||
- Creates new commits: Each time you use `git revert`, it creates a new commit that undoes the specified change. This means your Git history will still contain all previous commits. |
||||
- Can be used with multiple commits: If you want to revert multiple commits, simply specify their hashes or references (e.g., branch names) separated by commas. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git Revert](https://medium.com/@meghasharmaa704/git-revert-84727b543c17) |
||||
- [@video@Git Revert - Visualised](https://www.youtube.com/watch?v=XJqQPNudPSY) |
||||
@ -1 +1,14 @@ |
||||
# Git Stash Basics |
||||
|
||||
Git stash allows you to temporarily save your changes, or "stashes", when they're not yet ready for commit. This feature is useful when you need to work on multiple tasks, and want to switch between them without committing changes that are not complete. By using `git stash`, you can quickly stash uncommitted changes, reset the working directory to a clean state, and then apply the stashed changes later when they're ready for commit. This helps avoid cluttering the commit history with incomplete work, and allows you to maintain a clean and organized repository by separating your progress on different tasks. |
||||
|
||||
To apply a stash in Git, you can use the following commands: |
||||
|
||||
- `git stash apply`: This command applies the topmost stash (the most recent one) by default. It will merge the stashed changes into your current working directory. |
||||
- `git stash apply <stash_name>`: If you want to specify a particular stash, you can use its name instead of default. For example, if you've stored multiple stashes and want to apply an earlier one, you can use <stash_name>. |
||||
- `git stash pop`: This command is similar to apply, but it also automatically deletes the applied stash from the stash list. If you need more control over which stash to apply, using pop might be a better option. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git stash](https://www.atlassian.com/git/tutorials/saving-changes/git-stash) |
||||
- [@article@A practical guide to using the git stash command](https://opensource.com/article/21/4/git-stash) |
||||
@ -1 +1,12 @@ |
||||
# Git vs Other VCS |
||||
|
||||
Git has become the de facto standard for source control in software development, but it's not the only version control system (VCS) available. Here are some key differences between Git and other popular VCS: |
||||
|
||||
- Mercurial: Mercurial is a distributed VCS that uses a similar architecture to Git. However, it has a more centralized approach and doesn't use hashes for tracking changes. |
||||
- Subversion: Subversion is a centralized VCS that's often compared to Git. While both systems support branching and merging, Subversion requires a central server to manage the repository. |
||||
- Perforce: Perforce is a commercial VCS that's designed for large-scale development projects. It uses a centralized approach and has features like build automation and issue tracking. |
||||
- CVS: CVS is an older version control system that's still in use today. However, it lacks many modern features and is often considered outdated. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git vs. Other VCS: A Comparative Analysis](https://medium.com/@pascalchinedu2000/git-vs-other-vcs-a-comparative-analysis-5cb03ad58e0e) |
||||
@ -1 +1,8 @@ |
||||
# Git Worktree |
||||
|
||||
A Git worktree allows you to create multiple working directories for a single repository, each with its own checkout and index. Unlike a regular checkout, which creates a new working directory for a specific branch and updates your IDE's configuration settings, a Git worktree does not require you to switch between branches using git checkout. This means you can have multiple branches checked out at the same time without affecting each other or requiring changes to your IDE configurations. By creating a separate worktree for each branch, you can stage changes independently and maintain distinct working directories without impacting the main repository or its working directory. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Git Worktree](https://www.gitkraken.com/learn/git/git-worktree) |
||||
- [@video@Manage Branches easily using Git Worktree](https://www.youtube.com/watch?v=cRunWRC8ye0) |
||||
@ -1 +1,3 @@ |
||||
# 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. |
||||
@ -1 +1,6 @@ |
||||
# Unstaged Changes |
||||
|
||||
For changes that are not yet staged with `git add`, such as untracked new files or modified existing ones, use `git diff --unified`. This command compares your working directory against the latest committed version of each file. It's a useful tool for reviewing any local modifications before deciding whether to stage them for future commits. |
||||
|
||||
- [@article@What are unstaged changes in GitHub?](https://stackoverflow.com/questions/10954329/whats-the-unstaged-changes-in-github) |
||||
- [@article@How to unstage files in Git](https://www.git-tower.com/learn/git/faq/git-unstage) |
||||
Loading…
Reference in new issue