Git

Question 1

What is git stash?

Answer 1

Git stash lets you bring your working branch to the previous state storing un-committed changes in a separate place without any commit from where you can bring back those changes and apply those to your branch at any time.

Let’s assume you are working on a feature and you are just halfway now, suddenly you need to make a hotfix to a bug immediately. But since you are halfway through your feature you also don’t want to make a commit of your changes but you need to switch branches or make another commit. In this case, you might prefer stash and what it does is it takes all of your changes in a separate place taking your working branch to the previous state. Now you can work on the same or another branch, make a commit and you can also bring back all those changes to the branch whenever you want and you can carry on your work.

Question 2

What is git revert?

Answer 2

Git revert helps you undo any specific commit changes with a new commit.

Suppose you working on a feature & you find that there is a bug caused by one specific commit so you want to undo the changes of that commit. Instead of doing the changes manually git revert can undo those changes very easily. The advantage is that it does not change the commit history but adds another commit with the undo changes.

Question 3

What is git rebase?

Answer 3

Git rebase allows you to merge two branches without any extra commit (unlike git merge) to have a cleaner commit history.

This command allows you to rebase your working branch with another branch. You need to provide the branch name with which you want to rebase. If you want to rebase your feature branch with the main branch, you first need to checkout to feature branch and then provide the main branch name to the rebase command.

Question 4

What is git squash?

Answer 4

Git squash allows you to combine a branch’s multiple commits into one single commit. It also allows you to merge one branch into another while combining that branch’s commits into one single commit. If you made 5 commits in a feature branch and want to merge that branch in main but you want that in just one single commit you can do that using squash, as a result, you will see in your main branch that your feature branch is merged but instead of the main branch’s git history having 5 commits from feature branch there will be one commit.

Question 5

What is git cherry pick?

Answer 5

Git cherry-pick allows you to take specific commits from one branch & merge those into another branch. To do this first you need to find the commit hash of one or multiple commits that you want to take to another branch & you can do that by checking the commit history git log --oneline.

Question 6

Explain commit naming convention in git.

Answer 6

A commit message should start with a category of change. You can pretty much use the following 4 categories for everything: feat, fix, refactor, and chore.

• feat is for adding a new feature
• fix is for fixing a bug
• refactor is for changing code for peformance or convenience purpose (e.g. readibility)
• chore is for everything else (writing documentation, formatting, adding tests, cleaning useless code etc.)

After the category, there should be a “:” announcing the commit description.

After the colon, the commit description should consist in short statements describing the changes.

Each statement should start with a verb conjugated in an imperative way. Statements should be seperated from themselves with a “;”.

git commit -m '<category: do something; do some other things>'

Question 7

What Git hooks are in git?

Answer 7

Git hooks are scripts that run automatically every time a particular event occurs in a Git repository. They let you customize Git’s internal behavior and trigger customizable actions at key points in the development life cycle.

All Git hooks are ordinary scripts that Git executes when certain events occur in the repository. This makes them very easy to install and configure.

applypatch-msg.sample       
pre-push.sample
commit-msg.sample           
pre-rebase.sample
post-update.sample          
prepare-commit-msg.sample
pre-applypatch.sample       
update.sample
pre-commit.sample

Local hooks affect only the repository in which they reside. As you read through this section, remember that each developer can alter their own local hooks, so you can’t use them as a way to enforce a commit policy. They can, however, make it much easier for developers to adhere to certain guidelines. In this section, we’ll be exploring 6 of the most useful local hooks:

pre-commit
prepare-commit-msg
commit-msg
post-commit
post-checkout
pre-rebase

The first 4 hooks let you plug into the entire commit life cycle, and the final 2 let you perform some extra actions or safety checks for the git checkout and git rebase commands, respectively.

All of the pre- hooks let you alter the action that’s about to take place, while the post- hooks are used only for notifications.

Question 8

What is Trunk-Based Development in git?

Answer 8

Trunk-based development (TBD) is a branching strategy in which all developers make changes directly on the main branch, commonly referred to as the trunk, which holds the project’s deployable code. Developers are encouraged to commit frequently and use feature toggles (also known as feature flags) and other techniques to manage changes that are not yet ready for release. Testing is typically automated, with a focus on continuous integration (CI) and continuous delivery (CD) to ensure that code changes are thoroughly tested before they are deployed.

If a coding task requires an extended duration, possibly spanning over several days, the developer may create a branch from the main codebase, implement the necessary changes, and then merge it back into the main codebase once development is complete. However, the goal of trunk-based development is to minimize the use of feature branches and encourage developers to work collaboratively on the main codebase as much as possible.

Trunk-Based Development Workflow:

1. Work on the main codebase: Work directly on the main (trunk) branch, rather than creating separate branches.
2. Make small, frequent changes: Make small and incremental changes to the codebase, which are easier to review and less likely to cause issues.
3. Use Continuous Integration: Integrate and test the codebase frequently in order to detect issues early, avoid conflicts, and ensure that the codebase is always in a releasable state.
4. Merge changes frequently: Merged changes frequently back into the main codebase, keeping it up-to-date and reducing the likelihood of conflicts.

Question 9

What is Git Flow (Feature Branching) in git?

Answer 9

Feature Branching is a commonly used workflow that involves creating a new branch for a specific feature or change in the codebase. This allows developers to work on the feature independently without affecting the main branch. When the feature is complete, it can be merged back into the main branch through a pull request. The pull request allows other team members to review the changes and suggest modifications or improvements before merging the feature into the main branch.

Feature Branching Workflow:

1. Create feature branches: Create a new branch for each feature or task you’re working on. This branch should be created from the main branch.

2. Work on the feature: After creating the feature branch, you can start implementing the new feature by making as many commits as necessary. The branch should only contain changes relating to that particular feature.
3. Create a pull request: When you’re finished working on the feature branch, you create a pull request to merge the changes into the main branch.
4. Review and approve: Other developers review the changes in the pull request and approve them if they are satisfied with the changes. Code review can help catch issues or mistakes before they are merged into the main branch.
5. Merge the feature branch: Once you’re done working on the feature, you can merge the feature branch back into the main branch.
6. Clean up: After merging, you can delete the feature branch, as it is no longer needed.