DEV Community

11 Painful Git Interview Questions You Will Cry On

Alex 👨🏼‍💻FullStack.Cafe on July 30, 2018

According to the latest Stack Overflow developer survey, more than 70 percent of developers use Git, making it the most-used VCS in the world. Git...
Collapse
 
aershov24 profile image
Alex 👨🏼‍💻FullStack.Cafe • Edited

Hi Alex. First of all thanks for your comment. You are absolutely right - fork is not a Git concept and it's specifically stated just right after the words you've cited. In regards of server-side, hmmm... fork in Github (that the majority of teams are working with) is a "server-side" clone of repo. If you think it's wrong to mention it on an interview and that words drove you crazy you should probably delegate interviewing to someone else. Also there is a great practical interview question about "Forking workflow" in the article that you alas missed. And by the way it's great you've just warned people from potential working with you - I would personally avoid any professional relationships with "teams" or "devs" who use phrases like "not read further, you have no idea about, will never hire" in their lexicon ;) So good luck in boosting your "authority" amongst the community and have a great working day!

Collapse
 
moopet profile image
Ben Sinclair

Hi Alex and Aleksei

I think this thread is getting a little heated and that's not helping, and I don't want to fuel the fire, but I had exactly the same response as Aleksei - I got to your first definition and came to the comments to see if anyone had brought it up, and I didn't read any further at the time.

Alex, you used the phrase What is Git fork? and I immediately became confused since there's no such git command. It could be a typo for "what is a git fork" but since we're used to using git subcommands it seems to stand out.

It's easy enough to use the wrong words, and sometimes it's more important than others.

If I was conducting an interview around version control workflows and someone citing git was talking about servers, I wouldn't dismiss the applicant, but I would ask them to clarify so they had a chance to convince me that they knew what they were doing.

Thread Thread
 
aershov24 profile image
Alex 👨🏼‍💻FullStack.Cafe

Thank you for your reply Ben. As you stated the key point of any interview is to have a conversation around a question. I'm not pretending that the question "What is Git fork?" was intentionally created to confuse or derail a prospective but having to see in response the interviewee correction ("stars" would be immensely happy to do that) or mentioning that "a fork isn't a Git concept" for the rest of us is a solid and clear sign of a conceptually strong candidate (and that was "the" intention). It's again my pleasure to say thanks to you and AleX for pointing it out in a first place but let me leave that question title as it is to be the "anti-pattern" some people will stumble on and discuss :)

Thread Thread
 
ben profile image
Ben Halpern

Thanks for the comment Ben here.

Aleksei, I just want to note that you could have approached this whole situation in a much more constructive way. And since you're generally a great community member, I just want to remind you to take the time to address issues you see in a less provocative way.

I know you're acting in good faith, so just want to remind you that expressing tone on the web can be hard but we have high standards for community members to put in the effort to be good about this stuff.

Collapse
 
mtso profile image
Matthew • Edited

For Q10, one can also do git rm --cached <filepath> to remove the file from the git index and keep it in the working tree; which is the exact opposite of git add <filepath>. This will also work on filepaths that have been committed, which is especially helpful in the case of newly ignoring a previously committed file.

Collapse
 
jnareb profile image
Jakub Narębski

Also, conceptually git reset <filepath> is a wrong solution: it works only if you have not committed the addition of file (as you have said); git rm --cached <filepath> always work (though you need to remember that it removes the file only from future commits, and the file will be present in history).

Note that if you don't remember the command, git status would tell you how to do it.

Collapse
 
dandevri profile image
Danny de Vries

There are indeed some topics and concepts that only apply to social coding platforms such as GitHub. Maybe it's a good idea to specify this difference in the beginning of the post? 'The difference between Git and GitHub'

Collapse
 
cseeman profile image
christine

As a developer who has used both Github and GitLab, that could be another topic to explore, the differences between remote repo implementations and how the effect your workflow. Actually now that I have that written out, it might be the next topic I explore :) Thanks for your help with my brainstorming.

Collapse
 
maml profile image
Matthew Loseke • Edited

That's a great candidate for a post in and of itself.

Collapse
 
dandevri profile image
Danny de Vries

Maybe I'll write something up!

Thread Thread
 
harish1996 profile image
harish1996

I was about to do that... sometime ago..

Collapse
 
martinhaeusler profile image
Martin Häusler

Oh I've got a very clear answer when to use rebase: n-e-v-e-r. The process is obscure and the tooling is bad, even in modern IDEs such as IntelliJ it's not clear what is going on during a rebase. Just don't do it, the downsides by far outweigh the advantages. A force push is rarely a good idea. My team uses gitflow almost exclusively and we're quite happy with it, aside from the occasional "shouldn't we use rebase" discussion.

Collapse
 
jstocto profile image
jst-octo • Edited

I’d like to disagree. While it requires some caution, pull —rebase / regular rebase of live branches / interactive rebase before merge / merge —no-ff workflow leads to a much cleaner history and makes reorganization/disaster recovery much easier, at least to my taste.
If rebase implies force push on shared branches and if you rely on automagic GUI trickery in your team, then you probably need training and discipline more that a simpler workflow.

Collapse
 
martinhaeusler profile image
Martin Häusler

Sure, why not having a civilized conversation by starting off with implying that the other guy has no idea what they are talking about and "need training". Way to go.

I've heard the arguments - all of them, plenty of times, over and over again. I am fully aware of the advantages. And I still think that it's a bad idea. You may call it a "clean history" - I say this is not how it happened. The result of a rebase is an arbitrarily twisted and warped version of the actual project history. If the sole reason for a rebase is a straight line in gitk, then count me out. Sticking to gitflow with merge commits gives you a history that actually deserves the name because it is based on facts. It is a perfectly fine workflow, even juniors get it quickly. I see no reason to add more complexity to that. And rebase is not without caveats.

Thread Thread
 
jstocto profile image
jst-octo • Edited

Sorry if my tone was condescendent, I was just feeling that if your initial harsh rejection of rebase was because it was synonymous of force pushes and lack of proper GUI, it was pretty misguided.

If we start talking about the real stuff, then I’m not a gitk follower either. And I merge on trunks (no-ff), but after a rebase. Actually after regular rebases of living branches between their emergence and their merge. No rebase of shared branches (clone then rebase if the base is too old after a proper synchronization point), no push force either, publication of a private branch after rebase and before merge —no-ff to have the commits details on hand. Gitflow is ok to me, just feature/private branches handling feels better with rebases than with merges at least to me.
Sorry again if you took it personally, but you started 😝 by attacking cruelly my lovely rebase.

Collapse
 
jnareb profile image
Jakub Narębski

The main goal of rebase is to prepare a branch before submitting pull request (or equivalent), in the "blessed repository" workflow. It helps maintainer to have up-to-date changes, and less conflicts.

While at it, you can cleanup all the "fixup" commits with git rebase --interactive.

Collapse
 
cseeman profile image
christine

Is the "blessed repository" or integrator workflow similar to a forking workflow? I was trying to research the difference but they sound similar to me.

Thread Thread
 
jnareb profile image
Jakub Narębski

I am talking here about workflow titled "Integration-Manager Workflow" in the "Pro Git" book, chapter 5.1: Distributed Workflows.

Thread Thread
 
cseeman profile image
christine

Got it, the infographics are quite helpful with reading through git workflows.

Collapse
 
kutzowsky profile image
Michał K.

Excellent article. I won't cry, because i like git very much, but you're correct, those questions (at least some of them) are tricky and may cause problems especially during something as stresful as job interview.

Just one note: reverting a commit using reset is a bit too much in some cases and can be considered as a bad practice. For reverting single commit there's a "revert" command which is safer and can be better in some situations. "Explain difference between reset and revert" can be good interview question as well :).

Collapse
 
jerturowetz profile image
Jeremy Turowetz

Thanks for the article Alex.

For Q4 I feel you might be instructing users to do something a bit dangerous with git reset --hard HEAD~1.

If commit C has been pushed anywhere then using the above command local project will result in your local project history being different from upstream. This will cause conflicts if you try to merge later.

If you want to revert a commit that's been pushed it's much safer to use a command like git revert <commit>. This will introduce an extra commit, the reverse of the commit you're attempting to undo.

Though you end up with an extra commit no ones code will be broken, and this can be merged safely to remotes where the C commit might have been pushed.

You can read more on the git revert command here

Collapse
 
cjbrooks12 profile image
Casey Brooks • Edited

The terminology might not be 100% correct, because git itself doesn't have a concept of a "server" or a "fork", but the fact is that the vast majority of Git users do use Git concerning a server and forks. To git, there is no difference between a fork on a Github server and a clone elsewhere on my machine, but that knowledge really isn't necessary if you're not implementing the git protocol yourself or rolling your own Github. A fork is a remote copy of the repo, and that remote is a central server.

What I mean by this is that me, as a developer just picking up git, am going to get extremely confused trying to contribute to a Github project if I know understand the difference between a clone and a fork. I will commit changes to my local clone, but will not understand why they don't immediately go to my fork on Github. Describing the decentralized nature of Git in this sense is not going to help me in any way get my changes back into the master repo on Github.

To to reiterate, the git tool itself has no such thing as a "fork" and doesn't have a concept of a "server", and yet a fork is a very real thing in the git workflow, and just about any project you contribute to will have a centralized server. Not only is it rude to harshly criticize the author in this regard, but it misses the point of why the question would be asked. In an interview, the employer doesn't want to know if you understand the full protocol of git, they're asking if you know how to use their development workflow.

Collapse
 
hckmar9 profile image
Tere Diaz

Thanks this is so helpful. Part of the knowledge I've enforced and with your notes, it's easier to make my own notes. I think when someone shares part of their knowledge we should always compare it with what we know. :) Thanks for sharing.

Collapse
 
jstocto profile image
jst-octo • Edited

Nice article, I’d just like to add two pointers for those willing to push their git-fu further:

  • the reflog is a world on its own and mastering it allows among other things to solve the revert rebase problem (which isn’t one if you clone your branch before starting a rebase)
  • learngitbranching.js.org/ is pretty good to improve git skills

A last thing: with feature branches + rebase workflow, —no-ff is a must when merging to the trunk.
Thanks again for this nice article.

Collapse
 
l_giraudel profile image
Loïc Giraudel

I think the Q2 is not really clear, while it's more correct in StackOverflow link.

"A pull request is when someone take the repository, makes their own branch, does some changes, then tries to merge that branch in (put their changes in the other person's code repository)."

I would have said that a Pull Request is not a Git concept but a Git projects hosting (github/bitbucket/etc) concept where a UI is associated to a branch to discuss about its purpose, to review code changes and to emit remarks or suggestions before merging it to another branch.

In other words, it's a relational step in a development workflow where all involved parties can discuss before merging a code change to the main codebase.

Collapse
 
chakzefir profile image
chakzefir

I have a question about merging and saving the history of it. For instance, I have master and feature branch. When my feature is ready to deploy it goes to master and gets merged flag. So now we do not need this feature branch formally, so we are deleting it (actually gitlab has this feature to remove all merged branches at once). This gives us clean and up to date repository without mess of branches. And the question is, does git has the way to save branches history to recognise which feature-branch code was developed in?

Collapse
 
giacomosorbi profile image
Giacomo Sorbi

If you have any doubt, use merge.

I disagree: if you are in doubt, I would rather advise to learn how to rebase.

Also, for point 10, I would rather recommend git rm --cached, but it might be just me.

I don't think I am such a strong git power users, but no one of this questions seemed that hard to me; I would have expected some more sophisticated uses of this tool, including talking about strategies, rebase interactive, reflog, etc...

Collapse
 
dovidweisz profile image
dovidweisz

I'm just curious, do interviewers really ask such questions about git?

Unless you're applying for an SCM job and git is where you spend most of your time. I see that most of my peers don't know more than 3 or 4 git commands.

Collapse
 
offendingcommit profile image
Jonathan Irvin

This is a fantastic article, thanks for sharing Alex. Too often Git is seen as a chore and not a discipline. I try and convey that to any junior developer that crosses paths with me. Git is your chance for your code to tell a story about how it was made.

I expand on that in my latest cross-post from my Medium blog to here: dev.to/sublimegeek/check-out-these...

Sorry in advance for hijacking your post, that's not my intention. Just sharing my article for posterity.

Collapse
 
harish1996 profile image
harish1996

Q10: How to remove a file from git without removing it from your file system?

I think a better way to do this is git rm --cached filename ?? Correct me if i am wrong !

Collapse
 
subbramanil profile image
Subbu Lakshmanan

You are correct. From git-rm documentation

--cached
Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone.
Collapse
 
ysabri profile image
Yazeed Sabri • Edited

Great article, I just have a few things I need to point out that are wrong or inconsistent:

Q1 and forking:

I read all the comments that address this but I want to talk about it myself since none of them mentioned what I'm about to say.
You said the following:

A fork is a remote, server-side copy of a repository, distinct from the original. A fork isn't a Git concept really, it's more a political/social idea.
A clone is not a fork.

Well this is actually mostly wrong. A GitHub fork is a remote, server-side "copy". No it is not distinct from the original. And yes it is a actually a git concept under the hood. Lastly, a GitHub fork is actually a clone under hood.

The way GitHub does forks is through shallow clones (of depth 1, I think). So when you fork a repo on Github, on the server, under your own set of repos a shallow clone of the repo will get created. That shallow clone will only have the surface level commits of each branch with a alternates pointing to the original one. This is done to conserve space as it would be redundant to create a copy of the entire Git tree upon each fork. Moreover, by having the surface commits to build on top of, the forked repo can be integrated (pulled back) into the original repo without breaking history. Fun fact, clones can be done locally or remotely, meaning on the server the repo and its forked (ie. shallow cloned) counterparts can exist on the same hard-drive or different servers.

Q2 branches and pull requests:

You said:

A branch is just a separate version of the code.

Well this is not true since Git doesn't equal versioning, they are not the same thing. A branch is a pointer to a commit, state, snapshot (call it what you may) just like HEAD is a pointer "usually" to the commit the current checked-out branch points to.

You also said under about pull requests:

A pull request is when someone take the repository, makes their own branch...

They do not have to make their branch, pull requests can be done on existing branches. If they have to it is usually the contribution guide line of the project that requests it.

Q7 working trees and working directories:

You said:

The working tree/working directory/workspace is the directory tree of (source) files that you see and edit.

Well this is not accurate. This is also one the biggest misconceptions people have about Git. Working tree is a completely different thing from the working directory. Phrased in my own words, the working tree is the current file system tree state checked-out from the Git database. As for the working directory, it is not a Git concept, it is your normal working directory that you get by executing "pwd" for example. Most Git commands work on the entire working tree, meaning they do not care what your current working directory is. An exception is the status command, the paths given back after running it are relative to the working working directory but are checked based on the current working tree. Notice how the source you rephrased form just used workspace, which is another acceptable name for working tree. This is not your fault as the Git documentation is still inconstant about the distinction in some places, read this stackoverflow question for more info.

You also said:

The index/staging area is a single, large, binary file in...

Well no it is not necessarily large, it depends on the project size. I'm not going to go through the rest of the definition, the not part is at least correct.

Q9 using working copy:

Lastly, you used the term working copy here just cause the Atlassian tutorial used it without explaining that it is a synonym for staging/indexing area. This just takes away from the consistency of the article since you explain the the concepts beforehand using the latter terminology.

It was pointed out in other comments but I'll re-iterate. Taking content from other sources and re-presenting is difficult since they might not offer the best or most accurate explanation, it also opens more room for misinterpretation. I hope you actually end up fixing the points I provided for future reads as they might rightfully assume the information you provided is correct given that you link your sources.

Collapse
 
leob profile image
leob

Thanks, this is an extremely useful overview! Very clear ... as a git user you're using most of these concepts on a daily bases, but you'd be hard-pressed (me at least) to give a clear description of them, great to see them so clearly explained.

Collapse
 
rebaiahmed profile image
Ahmed Rebai

Now I didn't' understand the comparison between git rebase vs git pull? And another point I remember in a job interview they ask me about the difference between git pull vs git merge! and all I have to tell is that git pull = git fetch+git merge

Collapse
 
wplj profile image
wplj • Edited

these questions are more about a particular service, not a concept and principles. I would leave such interview, it is quite strange not to ask what git basically is (persistent hashmap, graph model etc). Not knowing particular commands in a shell is not an issue for an applicant, GUI tools would suffice for many people, knowing how it works under the hood is more important.

 
ash1eyish profile image
Ashley Maria

I think you could be a little more condescending here.

Collapse
 
qm3ster profile image
Mihail Malo

There are git interview questions? In CURRENT_YEAR? Scary stuff.

Collapse
 
sunflower profile image
sunflowerseed

do people actually ask you git questions in an interview? I thought they usually ask you some algorithms that took people months or years to solve and ask you to solve it in 20 minutes.

Collapse
 
yeppao profile image
yeppao

Great article !
Only one "m" on $ git commit --amend

:)

Collapse
 
fmmricardo profile image
Ricardo Martins

Great content Alex!
Thank you!!

Collapse
 
amitnishad profile image
amit nishad

That's a great candidate for a post in and of itself.

Collapse
 
swpalmer profile image
Scott Palmer

if you don't want to cry, just use Mercurial. Unlike Git, it has a sane UI.

Collapse
 
regul4rj0hn profile image
Mauro Lavigna

Basic stuff if you use Git on daily basis, but it is great to have it compiled in a single, neat post. Thank you!