GitHub collaboration notes

After my whining about pull requests Mike gave me commit access to the repo. Here’s some quick notes on some simple git stuff he helped me do. The setup is we both started working in on separate projects. He made a private branch, made a bunch of changes, then pushed them to the ditch-node branch. Meanwhile I had made my own pyconform branch off of ditch-node before his changes and wanted to bring mine in with his. We could have just merged, but Mike asked me to rebase so that my changes came after his to keep the history tidy. That was easy because there were no conflicts. Here’s how it went.

# Push my pyconform branch up to GitHub
  506  git push -u origin pyconform

# Fetch Mike's changes in ditch-node
  507  git fetch origin ditch-node

# In my pyconform banch, rebase with the changes in ditch-node.
# This happened automatically without extra work on my part, no conflicts
# No commit necessary.
  510  git rebase origin/ditch-node

# Try to push my newly altered pyconform branch to GitHub
  513  git push
# That didn't work because we've altered history and Git is confused.
# So now we have to force the push to rewrite GitHub's version of things
  514  git push -f origin pyconform

# At this point my pyconform branch is done and looks as if I'd forked it off
# of Mike's changed, even though really we were working in parallel. Now it's
# time to merge my changes back to ditch-node and get rid of the pyconform branch

# Switch to ditch-node
  515  git checkout ditch-node
# Pull in the changes that are on GitHub
  516  git pull
# Merge from my pyconform branch
  517  git merge pyconform
# Push the merged commits back up to GitHub
  519  git push
# Delete my branch locally
  520  git branch -d pyconform
# Delete the branch on GitHub.
  521  git push origin pyconform
# Ooops, that didn't work, so do this magic to remotely delete the branch
  522  git push origin :pyconform

I regret not being more comfortable with this kind of git usage. I am sort of OK with git by myself but it’s a lot more complicated when collaborating.

3 thoughts on “GitHub collaboration notes

  1. Naive question 1: what would this look like in your hypothetical (or maybe not hypothetical!) preferred workflow?

    Naive question 2: why did you bother pushing pyconform to github? It seems like that’s where a lot of the trouble in the above came from: you pushed, then rewrote history, then had to figure out how to delete it remotely. Were you doing that for backup reasons, or code review reasons, or something else?

    Annoying neckbeard comment 1: Rewriting history in public repositories is, in general, not a good idea.

    Annoying neckbeard comment 2: From the outside it looks odd to me that Mike asked you to rebase – trying to keep history linear in a DVCS isn’t a winning proposition. (And it’s also not reflective of how the development actually occurred!)

  2. Heh, thanks for the comments. FWIW unlike my other git posts this one wasn’t intended as an angry rant, just noting how stuff worked.

    I think the work flow was reasonable, even if some of the commands are a bit confusing. The main difference I’d make is just to accept merge commits as part of the deal. I’m with you that rewriting history is a bad idea, but most folks I know who use git are often rebasing to simplify their histories. My take on it is that git is not doing a good enough job presenting a comprehensible history, but I haven’t thought it through carefully.

    You’re right I didn’t need to put pyconform up on github this time. In other circumstances you might need to though. The “git push origin :branch-to-delete” syntax is pure magic.

Comments are closed.