DevOps
Git
4.7 Rating 48 Questions 33 mins read146 Readers
DevOps
4.7 Rating 48 Questions 33 mins read146 Readers
A commit is the group of -
Branches can be thought of as a timeline with commits. By default, the master branch is the main, primary branch that we usually work with. HEAD is a pointer to the last commit on the current branch. Remote is simply a refine, or a pointer, to a related repository somewhere that's not local and that could be within local network or enterprise network or somewhere out on the internet. Some examples of places that might be hosting remote repositories would include GitHub, Gitlab, Bitbucket etc.
On the terminal/cmd using 'git version' command; it will show the installed git's version. Using command 'git help'; we can display the list of commands supported by the git. Using 'git help <command-Name>' we can get the detailed information about specific git command; on windows it will be displayed in the web-browser but on Mac/Linux it will be displayed on the terminal itself. Command 'git help -a' gives a list of subcommands.
This is one of the most frequently asked Git interview questions for freshers in recent times.
Using 'git status' command in the repository working directory, when this command is used it will display-
If there is no file/folder to add or commit then it will just display name of the branch and message "nothing to commit, working directory clean"
There are two ways to add or stage the files or the changes to the git repository.
Using 'git add' command, this will add the file to staging Using 'git commit -am <your custom message>', the '-a' option with commit command will add the files to staging(not to 'newly added files' but only that have been modified and deleted) and commit too. basically 2 in 1, it adds then commit the files. '-m' options for providing the custom commit message.
Pull
$ git pull origin mastergit pull says "bring the changes in the remote repository to where I keep my own code."
Normally git pull does this by doing a git fetch to bring the local copy of the remote repository up to date, and then merging the changes into your own code repository and possibly your working copy. If you don’t closely manage your branches, you may run into frequent conflicts.
Fetch
$ git fetch origingit fetch is the command that says "bring my local copy of the remote repository up to date."
When you command fetch, Git extract all commits from the target branch that does not exist in the current branch and keeps them in your local repo. But, it does not merge them with your current branch. This is mostly useful if you need to keep your repo up to date, but are working on some solution that might break if you update your files. To integrate the commits into your master branch, we use merge.
git reset --hard HEAD~N- To undo last commit and changes.N stands for how far you would like to undo your changes. For undo last changes N=1 Let's talk about below use case where C is current HEAD while F is a state of files.
If you like to undo commit C. You do this:
Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.Suppose we would like to undo the commit but keep our changes before we do good commit. Let's start again with the above example, with C as our HEAD:
We can easily achieve this by, leaving off the --hard:
In both scenarios, the HEAD was just a pointer to the last commit. When we run a git reset HEAD~1, we ask Git to move the HEAD pointer one commit back. But (unless we use --hard) we leave our files as they were. So now git status will show the changes you had checked into C. Your files will remain as it is but only GIT HEAD has moved one commit back.
A single git repository can track any number of branches, but your working tree is always referring just one of them (the "current" or "checked out" branch), and HEAD points to that branch.
HEAD is the commit at the top of the current branch. If you've just checked out the branch, i.e. have no modified files, then its content matches the working tree. As soon as you modify anything, it no longer matches.
A working tree is the dir and sub-directory within it that contain the source files. It can be anywhere, but normally it is the same dir in which the hidden .git dir is located.
The index/staging area is a single, large, binary file in <baseOfRepo>/.git/index, which lists all files in the current branch, their sha1 checksums, time stamps and the file name - it is not another directory with a copy of files in it.
Sometimes we may end up adding files in our commit which we never intended to commit. Nothing to worry if you come across a scenario. The command git rm will remove it from both your staging area (index), as well as your file system (working tree), which may not be what you want.
We can use git rm --cached on the file if you want to remove from the version control cache but do not want to remove/delete from your filesystem. So if you wanted to remove foo.txt from version control like this just run this command:
git rm --cached foo.txt
We can also use below git commands to achieve the same result:
git reset filename
The above command is used to undo the local changes. Git reset operates on "The Three Trees of Git". These trees are the Commit History ( HEAD ), the Staging Index, and the Working Directory
This is a common yet one of the most important Git coding interview questions and answers for experienced professionals, don't miss this one.
The Forking Workflow is fundamentally different than other popular Git workflows. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer their own server-side repository. The Forking Workflow is most often seen in public open source projects.
The forking workflow can be summarized as below:
For example using GitHub as a remote repository
This is one of the most frequently asked Git interview questions and answers for freshers in recent times.
When reading/getting, the values are read from the system, global and repository local configuration files by default, and options --system, --global, --local and --file <filename> can be used to tell the command to read from only that specific location. When writing, the new value is written to the repository local configuration file by default(--local), and options --system, --global, --file <filename> can be used to tell the command to write to that location.
Using command ‘git log"; this command displays commits list(in chronological order) from latest to old one in descending order of the committed date. For each commit record it displays-
To remove a file for example 'myfile.txt'; which is already committed and a part of repository, the first step is to 'staging' this file deletion using 'git rm myfile.txt' command. After this command if we use 'git status' it will show message e.g. 'deleted: myfile.txt' . Now as second step to make it permanently we have to commit this staging using 'git commit -m <your message>' command.
Another way is if we remove the file 'myfile.txt' from the working directory manually for example using terminal rm command or using menu as we delete file normally using operating system's GUI. post manual removal the 'git status' command will display the message 'Changes not staged for commit:' and file information like 'deleted: myfile.txt'. To stage these manual changes(we can say same behaviour as working directory changes of add/remove/update files) we have to use -u (recursively update) option with add e.g. 'git add -u'(pre git 2.0 version) or 'git add .'(git 2.0 and above version) command. Then use git commit command to make them permanent.
