git FAQ

navigate the git diff of a pull request on you local machine
- https://stackoverflow.com/questions/37763836/how-to-make-git-diff-show-the-same-result-as-githubs-pull-request-diff
move forward and backward between commits in git
- https://stackoverflow.com/questions/6759791/how-do-i-move-forward-and-backward-between-commits-in-git?rq=3
view all commits from any HEAD/commit ref
- git log --all reversed: git log --all --reverse
git log N commits around "current commit"
- https://github.com/magit/magit/issues/2990 ?
- git log -n N (returns the previous N commits)
git checkout to the "next commit"
- https://stackoverflow.com/questions/6759791/how-do-i-move-forward-and-backward-between-commits-in-git
- this goes back: git checkout -f HEAD@{1}
clone a subfolder in a git repo
- git clone --depth 1 --no-checkout https://github.com/microsoft/vscode-extension-samples.git, cd vscode-extension-samples/, git sparse-checkout set test-provider-sample, git checkout
- https://medium.com/@judyess/how-to-clone-specific-subdirectory-branch-with-git-3fb02fd35b68
- https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository
scroll down a paged git result faster
- Spacebar: Scrolls down one page.
- Ctrl + D: Scrolls down half a page.
- Ctrl + F: Scrolls down one page (similar to Spacebar).
delete a newly created branch
- git branch --delete <branchname>
see the diff between two successive commits
- git diff HEAD^ HEAD
what command to run to see the commit msg/commit you're on
- git log -i
force checkout to a commit (ignoring all changes)
- git checkout -f <commit>
fix "error: RPC failed; curl 16 Error in the HTTP2 framing layers"
- https://stackoverflow.com/questions/72987674/git-pull-error-rpc-failed-curl-16-error-in-the-http2-framing-layer-fatal-exp
show git log in reverse
- git log --reverse or git log -p --reverse
Add all files to a commit except a single file? (https://stackoverflow.com/questions/4475457/add-all-files-to-a-commit-except-a-single-file)
git diff & list of staged files
Commit only a part of a file's changes?
git clone directly into project folder without creating new one
How to show branch hierarchy/tree on the terminal?
- git log --all --graph --decorate --oneline --simplify-by-decoration
Why doesn't git push push all commits from other branches?
- https://stackoverflow.com/questions/19088396/does-git-push-push-all-commits-from-other-branches
Why shouldn't git branches be used for semantic versioning an app?
- https://softwareengineering.stackexchange.com/questions/134754/is-it-a-good-practice-to-use-branches-to-maintain-different-editions-of-the-same
What is a detached HEAD in git?
😎
In Git, a "detached HEAD" state refers to a situation where the currently checked-out commit is not associated with any branch. Instead, you are directly pointing to a specific commit in the Git history. This state can occur for several reasons, and while it's not necessarily an issue, it's essential to understand when and why it happens.
Here's how a detached HEAD state can occur and what it means:
1. Checkout a Specific Commit: When you use the git checkout command followed by a commit's SHA-1 hash or a tag name, you switch to that particular commit directly, leaving your HEAD detached.
2. Checking Out a Tag: If you check out a tag (e.g., a release version), it points to a specific commit, and you will be in a detached HEAD state.
3. Checking Out a Remote Branch: If you check out a remote branch directly (not by creating a local tracking branch), you will also be in a detached HEAD state because you are not on a local branch.
4. After a Git Revert or Git Bisect: During operations like git revert (for undoing changes) or git bisect (for finding faulty commits), Git can place you in a detached HEAD state temporarily to let you inspect and test specific commits.
  
  In a detached HEAD state:
- You can view the commit's history, make changes, and even create new commits.
- However, these changes won't be associated with any branch, so if you create a new commit, you should save its SHA-1 hash if you want to keep it.
- Once you switch to a branch or create a new branch from a detached HEAD state, your changes will be associated with that branch.
  
  To return to a branch from a detached HEAD state, you can either:
- Use git checkout followed by the name of an existing branch. This will create a new branch from the current commit and check it out, effectively moving your changes to the new branch.
- Create a new branch with git branch <branch-name> while in the detached HEAD state and then check out that new branch with git checkout <branch-name>.
- Commit your changes and create a new branch from the commit to preserve your work.
  
  Remember that working in a detached HEAD state can be useful for inspecting, testing, or making quick fixes to specific commits, but it's generally recommended to work on branches when developing new features or fixing issues to maintain a more structured and organized Git history.
If I have a commit that is the 'root/base' of all the future commits of a branch, is it possible to make a change to a file in the 'root/base' commit so that the change is reflected in the future commits?
- Quick sad answer: NO?
Can you use the hash of a commit to overwrite the files in a different commit?
😎
Yes, you can use the hash of a commit to effectively overwrite the files in a different commit, but you should do this carefully as it involves rewriting Git history, which can have consequences if others are collaborating on the same repository.
Here are the steps to overwrite files in a different commit using Git:
1. Identify the Target Commit: Find the commit whose files you want to overwrite. Note its commit hash (SHA-1).
2. Create a New Branch: It's a good practice to work on a new branch to avoid affecting the existing branch's history. Use the following command to create a new branch from the target commit:
```
git checkout -b new-branch-name commit-hash
```
  Replace new-branch-name with the name of your new branch and commit-hash with the hash of the target commit.
3. Make Changes: Make the necessary changes to the files in your working directory. You can use any text editor or IDE to make these changes.
4. Stage and Commit: After making the changes, stage the modified files using git add and then commit the changes:
```
git add .
git commit -m "Updated files to overwrite the target commit"
```
5. Push Changes (Optional): If you want to share these changes with others or store them remotely, push the branch to the remote repository:
```
git push origin new-branch-name
```
6. Merge or Rebase (Optional): Depending on your workflow, you can choose to merge or rebase your changes into the original branch when you're satisfied with the modifications. This brings the changes from your new branch back into the main branch.
```
- To merge, use `git merge`:
  ```bash
  git checkout main
  git merge new-branch-name
  ```

- To rebase, use `git rebase`:
  ```bash
  git checkout main
  git rebase new-branch-name
  ```
```
Please be aware of the following considerations:
- Rewriting Git history can cause problems for collaborators if others are working on the same branch, so communicate with your team if necessary.
- Overwriting commits should be done carefully and sparingly, as it can make it challenging to track changes and understand the history of the codebase.
- It's advisable to create backups or snapshots of your repository before making significant changes that involve rewriting history.
  
  Always consider the collaborative aspects and best practices of version control when making changes that affect Git history.
How do you push the changes in all the branches to remote?
- git push origin --mirror

Backlinks

git internals