Git Flashcards
Types of VCS
- Centralized
- Decentralized
Centralized VCS
Single Point Of Failure (Google Docs)
Need to be online when making changes
De-Centralized VCS
- Clone the project
- No need to be online while making changes
- There can be conflicts while merging the code
Github, Bitbucket, Gitlab
Not VCS
Central servers that allows to store codebase managed via git
https://learngitbranching.js.org/
Commit Id
Created from the hash of previous commit ids
Git Rebase
Rebasing essentially takes a set of commits, “copies” them, and plops them down somewhere else.
While this sounds confusing, the advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log / history of the repository will be a lot cleaner if only rebasing is allowed.
Relative Refs
hash: fed2da64c0efc5293610bdd892f82a58e8cbc5d8
Specify enough characters of the hash until it uniquely identifies the commit. So I can type fed2 instead of the long string above.
Moving upwards one commit at a time with ^
Moving upwards a number of times with ~<num></num>
Centralized VCS (CVCS)
Storage: Files and historical data reside on a central server.
Examples: Subversion (SVN) and Perforce.
Pros: Simplicity and centralized control.
Cons: Single point of failure, limited offline capabilities.
Distributed VCS (DVCS)
Every contributor has a complete repository on their local machine.
Examples: Git and Mercurial.
Pros: Full repository backup, enhanced collaboration.
Cons: Complexity, larger repository size due to full copies.
Git Branching
Purpose: Diverges development from the main line.
Strategies: Feature, release, and long-running branches.
Best Practices: Regular commits, clear naming, and cleanup.
Git Merge
Process to combine changes from different branches.
Types: Fast-forward, three-way, and squash merges.
Git Rebase
Command to rearrange commit history.
Benefits: Provides a cleaner, linear progression of commits.
Detached HEAD
The term “detached HEAD” in Git refers to a state where the HEAD (the pointer to the current branch or commit) is directly pointing to a commit instead of a branch reference. In this state, you’re no longer on a branch and any commits made will not be associated with a branch, making them somewhat challenging to access or find later.
Causes of Detached HEAD State:
Checking out a Commit: If you use git checkout <commit-hash>, it switches to that specific commit rather than a branch. This results in a detached HEAD state.</commit-hash>
Checking out Tags: Similar to commits, checking out tags can lead to a detached HEAD state.
Implications and Usage of Detached HEAD:
Read-Only Mode: You’re in a state where you can view the commit’s content but not directly modify it.
Temporary Inspection: Useful for reviewing historical commits, checking differences, or testing specific historical states of the project.
Risks and Considerations:
Lost Changes: Any new commits made in a detached HEAD state might be challenging to find or access later.
Risk of Changes Lost: If you switch away from this state without saving changes or noting down the commit hash, those changes might be lost.
Recovering from Detached HEAD:
Create a Branch: If you want to keep changes, create a new branch at the current commit: git checkout -b <new-branch-name>. This action will create a branch at the current state, ensuring changes are not lost.</new-branch-name>
Save Changes: You can save changes by creating a new branch or by creating a patch or stash. Then, you can apply them to a branch later.
Git Cherry-Pick
Git cherry-pick selects and applies individual commits from one branch into another, useful for specific changes without merging entire branch histories.
When to Use Cherry-Pick
Selective Changes: Apply specific changes from one branch to another without merging entire histories.
Bug Fixes or Feature Backporting: Useful for applying fixes or features from one branch to another.
How to Cherry-Pick
Identify Commit Hash: Get the hash of the commit you want to cherry-pick.
Switch to Target Branch: Use git checkout [target-branch] to move to the branch you want to modify.
Apply the Commit: Execute git cherry-pick [commit-hash] and resolve conflicts if any. Push changes using git push origin [target-branch].
Best Practices for Cherry-Pick
Commit Isolation: Cherry-pick works best with isolated commits.
Testing: Always test changes after cherry-picking to ensure functionality isn’t compromised.
Avoid Overuse: Cherry-pick is useful but shouldn’t replace regular merging or rebasing.
git pull
git fetch + git merge
