Git

Question 1

Types of VCS

Answer 1

1. Centralized
2. Decentralized

Question 2

Centralized VCS

Answer 2

Single Point Of Failure (Google Docs)
Need to be online when making changes

Question 3

De-Centralized VCS

Answer 3

1. Clone the project
2. No need to be online while making changes
3. There can be conflicts while merging the code

Question 4

Github, Bitbucket, Gitlab

Answer 4

Not VCS
Central servers that allows to store codebase managed via git
https://learngitbranching.js.org/

Question 5

Commit Id

Answer 5

Created from the hash of previous commit ids

Question 6

Git Rebase

Answer 6

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.

Question 7

Relative Refs

Answer 7

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>

Question 8

Centralized VCS (CVCS)

Answer 8

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.

Question 9

Distributed VCS (DVCS)

Answer 9

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.

Question 10

Git Branching

Answer 10

Purpose: Diverges development from the main line.
Strategies: Feature, release, and long-running branches.
Best Practices: Regular commits, clear naming, and cleanup.

Question 11

Git Merge

Answer 11

Process to combine changes from different branches.
Types: Fast-forward, three-way, and squash merges.

Question 12

Git Rebase

Answer 12

Command to rearrange commit history.
Benefits: Provides a cleaner, linear progression of commits.

Question 13

Detached HEAD

Answer 13

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.

Question 14

Causes of Detached HEAD State:

Answer 14

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.

Question 15

Implications and Usage of Detached HEAD:

Answer 15

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.

Question 16

Risks and Considerations:

Answer 16

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.

Question 17

Recovering from Detached HEAD:

Answer 17

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.

Question 18

Git Cherry-Pick

Answer 18

Git cherry-pick selects and applies individual commits from one branch into another, useful for specific changes without merging entire branch histories.

Question 19

When to Use Cherry-Pick

Answer 19

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.

Question 20

How to Cherry-Pick

Answer 20

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].

Question 21

Best Practices for Cherry-Pick

Answer 21

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.

Question 22

git pull

Answer 22

git fetch + git merge