Last week I presented a quiz, which I’d created as part of an “introduction to git” day I’ve been running. This week, as promised, the answers.

Of course, by presenting answers I realise I’m setting myself up to be corrected on any number of fine (or not so fine) points. So by all means chip in with corrections.

Basic operations

• Describe the working directory, staging area and repository.
  • The working directory is where your files are that you’re editing, your usual workspace. The staging area (aka cache or index) is the tree that’s your next commit. The repository is your last commit, plus all the history.
• What two things does git rm myfile do?
  • It removes the file from the repository and removes it from the staging area.
• Where do the following commands get myfile from? (And in case you’re as clever as one participant: No, myfile is not a branch.)

git checkout myfile
git checkout HEAD -- myfile
git checkout 9bffd0 -- myfile

• The first one gets it from the staging area.
• The second one gets it from HEAD, which is probably the last commit on the current branch.
• The third one gets it from the specified commit.
• If git status says “Nothing to commit”, what’s in the staging area?
  • It contains exactly the same files, in the same structure, as what’s at HEAD in the repository, which is probably the last commit on the current branch.

Branches and tags

• What’s a branch, really?
  • It’s a pointer to a commit, which moves with you.
• If you want to continue from where you are now but on a new branch, what are the two steps to take (which can be rolled into one command)?
  • (i) Create a new branch, and (ii) switch to it. It’s easy to forget the second one if you do it in two steps. You can do it in one step with git checkout -b newbranch.
• How do you switch to another branch?
  • git checkout mybranch
• Branches and tags are very similar. Why? And what’s the difference?
  • They’re both pointers to a commit. The main difference is that tags have to be moved manually, whereas with branches the pointer (the branch) moves with you when you do a commit.
    

Remote branches

• What does alice/rel-1200 mean as a branch name?
  • It’s your reference to what alice has as branch rel-1200.
• What can’t you do with a remote branch (e.g. bob/refactored)?
  • You can’t move it yourself. Only git can do that via push, pull and fetch.
• If I fetch origin/master and then someone else pushes their master to origin, what happens to my origin/master?
  • Nothing. There’s no magic link between your record of origin’s master and origin itself.

Merging

• When does a merge conflict occur?
  • When the same part of the same file changes on both branches being merged.
• What is the last step of a merge if there no conflicts?
  • The last thing that happens, assuming all is well, is a commit.
• How do you signal you’ve resolved conflict in a file?
  • You use git add.
• What’s a fast-forward merge?
  • When you merge with a branch which is just successor of your current commit.

Pushing and pulling

• What two operations does git pull do?
  • Fetch and merge. (Although you can also get it to be a fetch and rebase.)
• Which branches will git pull origin pull down?
  • All the branches at origin.
• Which branches will git push origin push up?
  • Only the branches that origin already knows about.

Rebasing

• Why is rebasing called “rebasing”?
  • Because it moves the base of a line of commits onto the end of another branch.
• If you git rebase origin/master what line of commits gets moved where?
  • Your current branch (all the way back to where it meets origin/master) gets moved onto the end of origin/master.
• How do you signal a conflict resolution on a file during a rebase?
  • As with merge: git add.
• How do you continue the rebase after that?
  • git rebase –continue
• How do fetch and rebase in one command?
  • git fetch –rebase
• What flag prevents a multiway (traditional) merge?
  • –ff-only. This is a flag for the merge command. If you give it to fetch then it gets passed straight through to the merge part of the operation.
    
• When a commit moves as part of a rebase, what changes and what stays the same?
  • The commit’s author, date, and message stay the same. The change is the same, although that’s not strictly part of the commit. The resulting tree (which is part of the commit) is probably different, and the commit’s parent is different.
• What’s the danger in rebasing other people’s work?
  • A rebase changes the commits. So if you rebase someone else’s work, and then they want to build on top of that, they have to throw away their original commit. This could be a real pain for them.