For this answer instead of just telling the command, explain what exactly this command will do.
To get a list file that has changed in a particular commit use the below command:
git diff-tree -r {hash}
Given the commit hash, this will list all the files that were changed or added in that commit. The -r flag makes the command list individual files, rather than collapsing them into root directory names only.
You can also include the below-mentioned point, although it is totally optional but will help in impressing the interviewer.
The output will also include some extra information, which can be easily suppressed by including two flags:
git diff-tree --no-commit-id --name-only -r {hash}
Here –no-commit-id will suppress the commit hashes from appearing in the output, and –name-only will only print the file names, instead of their paths.
Commit object contains the following components, you should mention all the three points presented below:
<> A set of files, representing the state of a project at a given point of time
<> Reference to parent commit objects
<> An SHA-1 name, a 40 character string that uniquely identifies the commit object
<> It is always advisable to create an additional commit rather than amending the existing commit due to the following reasons:
- Doing the amend operation destroys the previously saved state of that commit. If only the commit message gets changes or destroyed, it's acceptable but there might be cases when the contents of the commits get amended. This results in the loss of important information associated with the commit.
- Over usage of git commit --amend can have severe repercussions as the small commit amend can continue to grow and gather unrelated changes over time.
There can be cases where we want to revert from the pushed changes and go back to the previous version. To handle this, there are two possible approaches based on the situations:
* Approach 1: Fix the bad changes of the files and create a new commit and push to the remote repository. This step is the simplest and most recommended approach to fix bad changes. You can use the command: git commit -m "<message>"
* Approach 2: New commit can be created that reverts changes done in the bad commit. It can be done using git revert <name of bad commit>
<> Sometimes we end up having certain files that are not needed in the git index when we are not being careful while using the git add command. Using the command git rm will remove the file from both the index and the local working tree which is not always desirable.
<> Instead of using the git rm command we can use the git reset command for removing the file from the staged version and then adding that file to the .gitignore file to avoid repeating the same mistake again.
git reset <file_name> # remove file from index
echo filename >> .gitingore # add file to .gitignore to avoid mistake repetition.
<> Feature branching – A feature branch model keeps all of the changes for a particular feature inside of a branch. When the feature is fully tested and validated by automated tests, the branch is then merged into master.
<> Task branching – In this model, each task is implemented on its own branch with the task key included in the branch name. It is easy to see which code implements which task, just look for the task key in the branch name.
<> Release branching – Once the develop branch has acquired enough features for a release, you can clone that branch to form a Release branch. Creating this branch starts the next release cycle, so no new features can be added after this point, only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it is ready to ship, the release gets merged into master and tagged with a version number. In addition, it should be merged back into the develop branch, which may have progressed since the release was initiated.
<> In the end tell them that branching strategies vary from one organization to another so I know basic branching operations like delete, merge, checking out a branch, etc.
Some basic operation in Git include:
Initialize
Add
Commit
Push
Pull
Git has an automatic merging feature that handles the merge commits on its own, provided the code changes have occurred on different lines and in different files.
But, in case of competing for commits where there are changes in the same lines of code of a file or a file has been deleted in one branch but exists and modified in another, Git is unable to automatically resolve differences and thus raises merge conflict.
In such cases, it requires your help to decide which code to include and which code to discard in the final merge.
A merge conflict can occur during merging a branch, rebasing a branch, or cherry-picking a commit. Once a conflict is detected, Git highlights the conflicted area and asks you to resolve it. Once the conflict is resolved, you can proceed with the merge.
It is a script through which you can instantly browse your working Git repository in a web browser.
This script sets up gitweb and a webserver to browse the local repository. It automatically directs a web browser and runs a web server through an interface into your local repository.
The answer is pretty direct.
To know if a branch has been merged into master or not you can use the below commands:
git branch --merged – It lists the branches that have been merged into the current branch.
git branch --no-merged – It lists the branches that have not been merged.
There are a couple of reasons for this –
1. The amend operation destroys the state that was previously saved in a commit. If there is just the commit message being changed then that’s not a problem. But if the contents are being amended then chances of eliminating something important remains more.
2. Abusing “git commit- amend†can result in the growth of a small commit and acquire unrelated changes.
This directory consists of shell scripts that are activated if you run the corresponding Git commands. For example, git will try to execute the post-commit script after you have run a commit.
One or more commits can be reverted through the use of git revert. This command, in a true sense, creates a new commit with patches that cancel out the changes introduced in specific commits. If in case the commit that needs to be reverted has already been published or changing the repository history is not an option then in such cases, git revert can be used to revert commits. If you run the following command then it will revert the last two commits:
git revert HEAD~2..HEAD
When you no longer require a specific stash, you can remove it by executing git stash drop <stash_id> command. If you want to remove all the stashes in one go from the repository then you can run git stash clear command.
<> In Git each commit has a unique hash. These hashes are used to identify the corresponding commits in various scenarios, for example, while trying to checkout a particular state of the code using the git checkout {hash} command.
<> Along with this, Git maintains a number of aliases to certain commits, known as refs. Also, every tag that is created in the repository effectively becomes a ref and that is exactly why you can use tags instead of committing hashes in various git commands. Git also maintains a number of special aliases that are changed based on the state of the repository, such as HEAD, FETCH_HEAD, MERGE_HEAD, etc.
<> In Git, commits are allowed to be referred to as relative to one another. In the case of merge commits, where the commit has two parents, ^ can be used to select one of the two parents, for example, HEAD^2 can be used to follow the second parent.
<> And finally, refspecs are used to map local and remote branches together. However, these can also be used to refer to commits that reside on remote branches allowing one to control and manipulate them from a local git environment.
Handling large binary files is a significant problem in git, and to handle this problem “Large File Storage†extension works well for Git. Simply install LFS on your local computer, and after this, your large files will not be stored in the local repository. Instead, it will be stored in a dedicated LFS cache and store.
The git push command is applied for uploading content to a remote repository from a local repository. Pushing can overwrite changes, so it should be used with caution.
While git reset changes the state of the branch to a previous one by removing all of the states after the desired commit, git revert does it through the creation of new reverting commits and keeping the original one intact.
Git branch –merged master – shows all branches that are merged into master
Git branch – merged – shows all branches that are merged into the head
Git branch – no-merged –shows all the branches that are not merged
<> the state of a project at a given point of time is contained in a set of files
<> Parent object commit references
<> A 40-character string that uniquely identifies the commit object called a SHAI name
It is very easy to resolve merge conflicts as Git allows you to go back to the previous state. Just use a “git merge –abort†command, and you will be able to undo the merge and start the task again.
It is preferable to create an additional commit because:
<> It might cause inappropriate changes
<> A correct activity that was recently saved in a commit might ruin the express
<> The chances are high that you miss including significant remains
The working tree, also known as the working directory or workspace, is the directory tree of source files. Whereas, the index, which is also known as the staging area, lists all the files in the current branch.
HEAD is known as the last commit, which was marked in the check-out branch.
By using the hash value of the particular commit, you can execute the below command to get the list of files that have been changed in a particular commit:
git diff-tree -r {hash}
This will list down all the files that have been modified, and also the files that have been added. The -r flag is used to list individual files along with their path instead of collapsing them in their root directory names only.
You can also use the below command:
git diff-tree –no-commit-id –name-only -r {hash}
–no-commit-id will retrain the commit hash numbers to come in the output. Whereas, -name will exclude the file paths and only give the file names in the output.
The command git checkout [branch name] will switch from one branch to another.
The command git checkout -b [branch name] will create a new branch and also switch to it.
Git Stash drop command or <stash_id> is used to remove a particular stash that is not required.
Git stash clear command is used when all the stashes are to be removed in one go from the repository.
Yes, you can. To recover a deleted branch, you should know the SHA off the top of your head. SHA or hash is a unique ID that Git creates with every operation.
When you delete a branch, you get the SHA displayed on the terminal:
Deleted branch <your-branch-name> (was <sha>)
You can use the below command to recover the deleted branch:
git checkout -b <your-branch-name> <sha>
If you don’t know the SHA for the commit at the tip of your branch then you can first use the git reflog command to know the SHA value and then apply the above checkout command to restore your branch.
git reset --mixed command is used for undoing changes of the working directory and the git index.
git merge --abort command is used for stopping the merge process and returning back to the state before the merging occurred.
Some of the best GIT client for LINUX is
a) Git Cola
b) Git-g
c) Smart git
d) Giggle
e) Git GUI
f) qGit
To fix any broken commit, you will use the command “git commit—amendâ€. By running this command, you can fix the broken commit message in the editor.
There are couple of reason
a) The amend operation will destroy the state that was previously saved in a commit. If it’s just the commit message being changed then that’s not an issue. But if the contents are being amended then chances of eliminating something important remains more.
b) Abusing “git commit- amend†can cause a small commit to grow and acquire unrelated changes.
The git reset –mixed command undoes the changes made in the working directory and staging area.
The git merge –abort command stops the merge process and returns to the state before the merging began.
Git diff is a multi-use command that can be executed to show the differences between two arbitrary commits, changes between the working tree & a commit, changes between working tree & an index, changes between two files, changes between index & a tree, etc.
The git status command is used to inspect a repository. It shows the state of the working directory and staging area. It will list down the files that have been staged, which haven’t been staged and the files that are untracked.
The commit object contains the top-level tree object hash, parent commits hash(if any), author and committer information, commit date and commit message.
To co-ordinate with the distributed development and developers team, especially when you are working on a project from multiple computers ‘Bare Repository’ is used. A bare repository comprises of a version history of your code.
To co-ordinate with the distributed development and developers team, especially when you are working on a project from multiple computers ‘Bare Repository’ is used. A bare repository comprises of a version history of your code.
Both rebase and merge commands are used to integrate changes from one branch to another but in a different manner.
As seen in the below two images, suppose you have commits (this is before merge/rebase). After the merge, you will get the result as a combination of commits. It binds together the histories of both the branches and creates a new ‘merge commit’ in the feature branch.
The syntax for rebase command is git rebase [new-commit]
You can use the ‘cached’ option for this:
git rm -rf –cached $FILES
This command will remove the files from your repository without deleting them from your disk.
The git-add command adds new or changed files in your working directory to the Git staging area. Running the git add command will not change any of your work in the Git repository. Changes are only made to your repository when you execute the git commit command.
In simple terms, when you change and save a file (or multiple files, then, before you commit, you must git add. The git add command selects that file, and moves it to the staging area, for inclusion in the next commit. You can select a specific file, all files, a directory, or specific parts of a file for staging and commit. We can perform the add command multiple times before a commit.
Below is the syntax for the git add command:
git add [filename]
The git annotate command tracks each line of the file based on the commit information. It annotates each line within the given file with information from the commit which introduced that change. The annotate command can also annotate from a given revision.
Below is the Syntax of the git annotate command:
git annotate [<options>] <file> [<revision>]
Git bisect command uses a binary search algorithm to find the commit in your project’s history that introduced a bug in your code. The git bisect command divides the history of your project into the good and the bad commit range. It points your current project state to a mid-range commit snapshot. Now, this command moves through every commit id between this range while pausing at each snapshot to allow you to test the code. You declare the commit as bad if the bug exists.
The Syntax for the Git bisect command is:
git bisect <subcommand> <options>
The following are the two ways to squash the last N commits into a single commit:
Use the below command to write the new commit message from scratch
git reset –soft HEAD~N &&git commit
To start editing the new commit message with a concatenation of the existing commit messages, you will have to get those messages and pass them to commit:
git reset –soft HEAD~N &&git commit –edit -mâ€$(git log –format=%B –reverse .HEAD@{N})â€
A .git directory consists of all the metadata of the repository. It also keeps a track of all the changes made to the files in your repository, by keeping a commit history. It keeps all information related to commits, hooks, refs, object databases, etc.
When you create a repository, you will find a .git directory inside it. If you clone any git repository on your local machine, the .git is the directory that gets copied.
git-pull - Fetch from and integrate with another repository or a local branch
SYNOPSIS: git pull [options] [ […?]]
In its default mode, git pull is shorthand for git fetches followed by git merge FETCH_HEAD. More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. should be the name of a remote repository as passed to git-fetch.
Git is a revision control system, a tool to manage your source code history.
GitHub is a hosting service for Git repositories.
GitHub is a website where you can upload a copy of your Git repository. It is a Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features.
You can use git rm <file_name> command to remove a file from git.
git init will create a new git repository. It can also be used to convert local directory into git repository.
Pull is a fetch and a merge. * `git pull origin master` fetches commits from the master branch of the origin remote (into the local origin/master branch), and then it merges origin/master into the branch you currently have checked out.
To save all the project files in a git repo, below steps needs to be performed inside the project root directory :-
a) git init
b) git config --global user.email "Your Email ID"
c) git config --global user.name "Your Name"
d) git add .
e) git commit -m "Add Your Comment here"