Mastering Git - Object Model Operations

Upcase
1

© 2012 - 2015 thoughtbot, inc. Upcase, the design of a robot, and thoughtbot are registered trademarks of thoughtbot, inc.

This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/git-object-model-operations
3

A small nick-pick: around minute 24:40 when explaining a non-FF merge, the commit that “links” master and the feature branch together has the same SHA1 than the latest master commit, while actually it would be completely new commit.

4

Hey @javierholguera, you are, unfortunately, completely right (and I am so sad to see it). I’ll have to update this soon. Thanks for pointing it out, and nice attention to detail!

6

Hey @christoomey, I’m enjoying the Git trail so far. I noticed around 7:30 there was mention that lightweight tags are more common that annotated ones. The Git Book recommends using annotated tags, especially for releases where signability is important. Another advantage to annotated tags I’ve seen in my work is the ability to git describe a commit to see what tag precedes it.

What’s your opinion on the distinction and utility of the two different tag types?

7

I actually almost never use tags. The only time I do is to mark a released version of a repo so github will display the release page, and for that use case either works. I think any specific distinctions would be situation dependent.

8

hey Chris, sorry to bump this old thread - just having trouble finding any resources that explain --no-ff and --ff-only well.

Is it possible to incorporate the --ff-only in a push local to github, merge PR to master, pull down workflow, or is that impossible?

If so, what does that mean that thoughtbot espouses that as a best practice?

9

Hi @yakschuss,

Quick summary:

  • --ff-only will on merge via “fast forward”. This requires that your branch / commits are built on top of the branch you want to merge. A “fast forward” merge is then only the act of updating the base branch, typically master, to point at the most recent commit of your branch. The key distinction is that no new commits are created, the only change is to update what the base branch points to.
  • Conversely, --no-ff will create a new commit to mark the point where the two branches are brought together. Some teams prefer this for being able to track when merges happen.

Github offers a few merging options these days, which you can read up on here in their merging a PR documentation page.

You can read up on thoughtbot’s preferred git workflow in our guides. We prefer to keep feature branches as small and short lived as possible, and as such we prefer a rebase + squash approach so that we have a simple, clean, and linear development history.

10

Thanks Chris!