Skip to content

Instantly share code, notes, and snippets.

@nsu
Last active August 29, 2015 14:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nsu/78a06011045a02289699 to your computer and use it in GitHub Desktop.
Save nsu/78a06011045a02289699 to your computer and use it in GitHub Desktop.

Okay, so you're Ian Fleming, and you're starting work on a new chapter of a book.

At the end of the last chapter, 007 saved a pretty lady from a gang of komodo dragons released by an international terrorist organization that was posing as an Javanese drug cartel. Your editor has looked over that chapter, and, after some changes, she's now happy with your work. So you...

$ git checkout dev-chapter17

work happens…

$ git commit -m "remove clothing from female protaganist"

work…

$ git commit -m "refactor the fucktor"

work…

$ git commit -m "rough draft of komodo re-entry"

Now at this point you're only partially through the chapter, but it's going to be a long chapter, and you want your editor to look over it now. How do you continue working on the chapter while your editor reviews your completed work?

Some options

a) You shouldn't have used dev-chapter17 in the first place. Your feature branch should be as small as you will want a code review on. Maybe it could have been dev-ch17-komodo-sex

b)

  1. $ git push origin dev-chapter17

  2. Create a code review request without a merge request. After all, this chapter is only partially finished. Merging to the master branch when it's not ready to go to the printer is obviously inappropriate.

  3. $ git checkout -b dev-chapter17-wip

  4. work on the wip branch

  5. check out onto the dev-chapter17 branch to make changes suggested by reviewer

  6. after review is complete, merge dev-chapter17-wip into dev-chapter17

There has to be something better. In option (a) you can end up with super fractured development branches. When writing a large feature, you can easily write hundreds of lines. The more lines a reviewer looks at at once, the less likely they are to do a good job reviewing. And then you end up with a bunch of branches that are fractions of the completed work, which is okay, really, but it's weird. Option (b) just doesn't feel like git to me, and it seems a little convoluted.

In either case, I guess you need some sort of "dev" branch for merge requests that aren't feature complete?

I feel like there is a know, agreed upon way of solving this problem and I don't know it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment