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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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 ofgit 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 statuswould 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.
That's a great candidate for a post in and of itself.
Maybe I'll write something up!
I was about to do that... sometime ago..
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 revertcommand hereThe terminology might not be 100% correct, because
gititself 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. Togit, 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
gittool 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.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.
Nice article, I’d just like to add two pointers for those willing to push their git-fu further:
A last thing: with feature branches + rebase workflow, —no-ff is a must when merging to the trunk.
Thanks again for this nice article.
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.
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?
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.
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.
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
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:
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:
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:
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:
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:
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.
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.
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
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.
I think you could be a little more condescending here.
There are
gitinterview questions? In CURRENT_YEAR? Scary stuff.do people actually ask you
gitquestions 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.Great article !
Only one "m" on $ git commit --amend
:)
Great content Alex!
Thank you!!
That's a great candidate for a post in and of itself.
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!