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... [Read Full]
markdown guide
 

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.

 

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.

 

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'

 

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.

 
 

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.

 

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.

 

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.

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.

 

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.

 

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.

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

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

 

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 :).

 

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

 

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.

 

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.

 

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.

 

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 !

 

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.
 

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

 

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.

 

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?

 

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.

 

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.

 

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.

 

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.

 

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

:)

 

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

 

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

 
 

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

 

A fork is a remote, server-side copy of a repository [...]
A clone is not a fork; a clone is a local copy [...]

This is plain wrong. There is no such thing as “server” in the git paradigm. Even more: there is no such thing as fork in git at all. It is github-specific stuff. It is a clone that has it’s own github (and bitbucket FWIW) interface.

You mislead (read: fool) people not so familiar with the concept by publishing things you have no idea about.

I have not read further, but I feel a necessity to warn future readers: please beware of this content is not correct by any mean. If I got an answer involving a word “server” on the interview on git, I would never hire the applicant.

 

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!

 

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.

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 :)

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.

we have high standards for community members

Last time I have read that it was Orwell’s “1984.” It’s not gonna happen. Excuse me, but I’m not marching in formation. Simply put, I was grown to respect freedom of speech, liberty in general, consideration of diversity.

Applying “high standards” in a way of tentatively prompting a manner I am supposed to express my opinion does not conform to any of the above. Diversity does not mean “anything that suits the list of permitted” as well as freedom of speech does not mean “anything that corresponds to the rules.”

Linus Torvalds is obliged to reply to the same accusations on the regular basis and I would cite my favorite quote:

Do you really want to oppress a minority? Because Finns are a minority
compared to almost any other country. If you want to talk cultural sensitivity, I'll join you. But my culture includes cursing.

Response to Sarah Sharp’s bullying

Please note that I never bully for the sake of bullying, but even if I were, you only have an option to ban me (after all it’s a private club and I am fine with that.) Telling me to behave differently is unacceptable, sorry for saying. I believe that people around, specifically in developers communities, are mature enough to be able to defend their points of view and opinions without being babysitted by strong regulation rules implied by the Ministry of Truth.

Also, you are probably to decide what do you value more: how provocative is a way of expressing an opinion in comments or how high is the average quality of the articles and/or discussions. Whether the main goal of running this site is to make people happy reading “That’s cool” replies to any crap published—I’m fine with that. That won’t make me happy, but I’m fine with that too; that’s how things in the democracy (read: majority rule) use to happen.

I just want to warn you that vaccination was invented as an immunoprophylaxis. It saved a lot of human lives. And if you are banning me and me-like members of the community, having as per your admission a good faith (which is true btw,) sooner or later you’ll face the immune deficiency against harsh statements. Which is—trust me—way more offensive and insulting.

This happens to be the too long answer that is honestly not implying an answer. I wanted you to read this to puzzle you and to make you ponder the thing.

 

It’s not surprising you don’t understand the difference between git and it’s web frontends like github since you were not even able to spell my name correctly.

If you think it's wrong [...]

I do not think it’s wrong. I know it’s wrong.

that words drove you crazy

Excuse me? I bother about future readers, who might mistakenly think that everything published on the internet is written by competent people which is obviously not the case. I just warn future readers. If I were to drive bonkers every time somebody publishes crap, I would end up my days in the nuthouse.

 

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.

 

the fact is that the vast majority of Git users do use Git concerning a server and forks

You likely have a proof of this statement in your pocket. Otherwise is sounds like a nonsense.

that knowledge really isn't necessary if you're not implementing the git protocol yourself

What? The protocol? I have a ton of git repositories on HDD only and—you know what?—I do not implement any protocol neither do I roll my own Github. I use VCS exactly as distributed VCS is intended to be used. And, BTW, as it’s creator using it.

Without damn fancy web interface.

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 feel a pity you dare to enter the discussion on the topic then.

yet a fork is a very real thing in the git workflow

Nope unless you use Github/Bitbucket.

just about any project you contribute to will have a centralized server

Nope, that is not true.

Not only is it rude to harshly criticize the author in this regard

Since when copy-pasting the content written by strangers from Stack Overflow is called “authoring”?

So, you blame me for being rude pointing the copy-paster to mistakes. Cool. Now I am to explain what is indeed rude. Fooling people with wrong content is rude. Unwillingness to fix issues after many people have pointed out (other do in a less rude manner, if that matters) is rude. Intentionally distort interlocutor’s name is rude.

Warning future readers to not get the wrong content as a sacred truth, just because it was published in the internet is not rude. It’s socially significant action, that everybody who cares about people must perform in the first place.

In an interview, the employer doesn't want to know if you understand the full protocol of git

Really? On the interview on git? Sounds dubiously.

code of conduct - report abuse