My Ideal Git Workflow

I went to go look at another team’s code repository recently to try to find something and I couldn’t help but notice that their git history was a mess of merge commits and confusing commit messages.

Now, there aren’t hard and fast rules for how to git (no, really.), but I am of the opinion it is generally helpful to keep a clean history to tie changes in individual files to tickets. If you can do this with a single merge bubble per feature or something else, more power to you.

What follows is how my team and I prefer to maintain our git history.

Avoid Merge Bubbles with Rebase

Instead of just merging your branch into master after a Pull Request closes (never trust Github’s automatic merge!), try this instead:

# make sure your local copy of master is up to date
git fetch
git checkout master
git merge --ff-only origin/master

# rebase your feature branch against master
git checkout my-feature-branch
git rebase origin/master

# this rebase may have caused conflicts
# just resolve them like you would a merge, then...
git add .
git rebase --continue

# update your branch after rebasing, for posterity. 
# you need to force the push, because of the rebase
git push -f origin my-feature-branch

# finally merge the branch cleanly
git checkout master
git merge --ff-only my-feature-branch
git push origin master
This process completely avoids merge commits and the associated bubbles. Your git log will always show a single unbroken thread for whatever branch you are on.

Advanced Tip – The Release Branch

If you use a secondary branch like “release” or “develop” for building to a Test environment (vs master branch for QA/Prod), the easiest thing is to just merge the branches twice. Once on your test build branch (without rebasing). Then after the ticket is approved to go up the stack, rebase against master and merge, as shown here. Then rebase your test build branch on master (like it was a feature branch), which will remove any merge commits you have added.

Commits and Commit Messages

There are many ideas of what makes a good commit message, but focusing just on the initial subject line, I recommend:

[404] Create default error page

or, if you are on JIRA instead of Github for issue/ticket numbers:

[PROJECT-404] Create default error page

The message should be present tense, clear, and short. The textual tag of the issue/ticket number is optional, but very helpful when scanning a git log.

As far as commits themselves, I would recommend committing as often as possible during development, and don’t worry over much about messages at this point (especially longer descriptions). At least commit once per day, if only to be able to push your changes up.

When you are ready to do a Pull Request, use git rebase -i HEAD~10 (or how ever many commits you have) to merge several of them together into logical pieces. Feel free to rearrange or edit commits at this point, reducing the number to minimum logical groupings. For smaller features/bug fixes, a single commit at the Pull Request stage is recommended.

After the Pull Request, squash all of your commits together, unless your Pull Request comprises multiple unrelated shippable features, then squash the commits down to one per shippable feature.

On Code Reviews

Or, How I Learned to Stop Worrying and Love the Squirrel

kihroxvh_400x400

In a couple weeks I will celebrate 7 years of professional development. In those years, I have committed code to production in a variety of ways. I have SFTP’d files up to a live server. I have merged feature branches to a master branch. I have committed directly to master in a CI/CD workflow. I have participated in several iterations on git flow style branching. I have rebased live history, sometimes to great effect (removing an excessively large data file from our code’s history), and sometimes to great pain (having to manually rebase a dozen different branches to remove a couple commits that weren’t ready for prime time).

For the first several years of development, these code commits were largely autonomous and lacking any significant review. If they were reviewed, it was only to make sure the new code worked as expected and didn’t have any hidden problems, because we weren’t doing automated testing either. I was growing in skill by sheer attrition, sometimes debugging issues in production, sometimes spending days trying to reproduce issues locally, but only getting fundament development guidance from the occasional blog post or podcast.

In the past couple years, it has been a different story. My previous job was at ePublishing, an all-remote team with excellent developers and well defined standards and practices. It was here I was first shown what a pull request could be: with useful feedback on best practices and standards and multiple people participating and eventually signing off on each review. One rule was made very clear: on any non-trivial change, two :shipit: 🐿s (or :+1: 👍s) were required. This made the call on what was approved very easy to tell, though it sometimes left the PR discussion a little lacking.

A year ago today (8/3) I started working for Ramsey Solutions, a company that does “work that matters” in areas like personal finance and business leadership. This is a great company with great team members, but when I started I noticed some gaps in the code review strategy (or lack thereof). I was back to the wild west of optional reviews, and fast/shallow analysis of the code when it did get reviewed. So I resolved that (at least on my team) things were going to be better. With the help of my leader our team started using the two squirrels strategy I was used to on all our PRs going forward. This helped quite a bit on it’s own, because it got more people reading the reviews, which in turn gave more chances for discussion. But as the team grew, we didn’t have any consistency with the amount or severity of feedback we were giving besides the final :shipit:. In addition, we sometimes were giving “half-shipits” via the :+1:, which led some to wonder whether the code was good to go or not. Several of us on the team also started inserting things like “⛵️-it” or “🐏-it”, which, while amusing to punny people like me, really confused our newer team members.

A few months into this practice, at a quarterly team planning session, we discussed “the PR problem” and eventually codified some new rules and concepts.

Firstly, we decided that you could no longer leave :+1: (or anything else, no matter how punny) as a final meaningful response on a PR. If you are going to participate in the code review at all, you must drive the PR forward until you feel comfortable with a :shipit:. To this end, you might need to add tickets to the backlog to fix things that could not be addressed in this PR. These tickets are new technical debt for the project and should be remedied as quickly as possible so that paying down the the interest doesn’t overwhelm new work.

Secondly, we decided to call out (literally, label) four severity levels of comments you can leave, and we clearly defined each level:

  • The :shipit: is the first and most obvious severity level and means you are 100% OK with this code being in production as-is.
  • The next severity is blocking which, as its name implies, points out something that prevents the author from giving a :shipit: until resolved (either in this PR or as a new ticket). These can range in cause anywhere from critical logic issues to coding/design standards violations. As long as you won’t give approval until it is resolved, it is blocking.
  • The middle severity is rocking. These are the “nice to haves”, things like refactoring messy code or following a standard that is not officially codified, or less important.
  • Note: If you only give rocking feedback or below, you should also give a :shipit:, because you didn’t find any blocking problems. The committer should read all these comments and at least consider whether now is a good time to make the change, or even if they agree with it (discussion is encouraged!). These comments can also be sources of tech-debt tickets if the committer agrees the change should be made, just not right now.
  • The lowest severity comment is talking. These are questions and general comments on the code, including :+1: as praise for a particularly well written line of code (or refactor/deletion of a poorly written one!). These often require no action unless there is a question attached, but should still be reviewed before merging.

Third and finally, we started leaving comments on specific lines of code wherever possible so that when the comment was addressed the discussion disappeared, hopefully leaving a fairly clean diff at the end (:shipit:s being the one kind of comment that is encouraged only at the top level).

After this first draft of rules was decided at our quarterly planning session, the quality of our code reviews went up drastically. Everyone committing code knew exactly what to expect when they submitted their PR, and conversations were much more focused because the original commenter gave their feedback a reasonably severity level. A lot of the discussion around rocking and talking comments has helped us to codify new standards/guidelines for our code base, where as the non-committal :+1: which might have been given before would often fail to generate a conversation.

After we had been using these conventions internally for a while (and as our team grew) we started using them when giving feedback on code reviews outside our immediate team. This caused some confusion initially, so one of our team’s developers gave a short talk about the convention at the next technology team meeting (our team is about 8 people, but there are over 80 people in the technology space here). Other teams then started adopted the standard, some of them replacing the English terms of blocking, rocking, and talking with emoji for brevity: 🚫, 🎸 (or 🤘), and 💬. Our team had actually discussed this but decided against it at the quarterly meeting because it seemed too finicky, but more power to the teams that decided to use them as long as they are consistent and clear.

I have really appreciated the level of feedback we have on code reviews now, and of course we are always looking for more methods to improve the experience even more. But discussing processes like this one with your team, even if you think you are doing everything all right, can be very instructive because the discussion itself can help further define things even if no actual changes are needed.

So go out (or possibly stay in) and improve your workplace environment today!


 

PS: After several months of using the new conventions, our team had a chance to work on a large project under a tight deadline. Since we were spread so thin, our fearless leader (er, our Director of Technology) decided to take a hand in approving PRs. He declared by fiat that his :shipit: squirrels were worth two of ours, so we lovingly created a special :leadershipit: emoji on Slack just for him.

773a89c1682f2c37

On Preferring Pornography

So, I want to begin with a disclaimer. While there is a comparison between women and food in this post, the point is not to objectify women. The point is the opposite: to humanize them. So don’t just glance at the pictures or a pull quote and leave nasty comments, ok? (at least wait until you have read the article and have actual opinions on what I said)

What This Post Isn’t About

I am not here (today) to talk about why Christians shouldn’t watch porn. That is a whole other post for another day entirely. I am really just speaking to the general population. I am also not setting out to keep anyone from watching porn. –Though really, why? There are so many better (and more pleasant) things to do with your time.– Instead I want to talk about the relative merits of preferring porn when you are in a relationship with someone.

Who am I?

I’m just a guy who (like most guys) has looked at porn in the past. I have even done so while in relationships. It has never been a good choice, and I hope that part of my life is done for good at this point.

Porn vs Movies

What you see when you watch porn is a front. (also an affront, but more on that another day) It is a farce, a pretense, not even worthy of being called fiction no matter how many “plot lines” they attempt to have in a pornographic video. There is no substance, no story, no soul. There are just sexual objects performing the basic function of sex.

This isn’t like watching the latest super hero movie, horror/thriller or chick flick. Those were all stories, written by someone who (generally) knew how to tell a story, and then portrayed in film as a medium. The people in them are actors, playing parts as directed, but also giving their own flavor to a role. Humanoid CGI characters in movies will probably always have to be modeled after real actors, not because technology isn’t good enough to render them in the various poses, but because we (the audience) care about the subtle emotions a real person has.

Sure the actors all have makeup on (even the guys) and sure the director is trying with each scene to make you feel some particular emotion: maybe excited or scared or joyful or thoughtful. But these feelings persist long after the movie ends and are associated largely with the story, not the acting itself. The acting was just the thing that gave the story life like words read off a page. The story lives on in you and you can perhaps imagine yourself as one of the actors –performing the part event better than they did– because now it is your story, and not the director’s.

15660-illustrated-silhouette-of-a-beautiful-woman-pvWomen in Porn

Porn is different. There is no real story behind the guy and the girl on screen. They are only there for one purpose: to sexually arouse you. You might imagine yourself as the guy having sex, but this isn’t inserting yourself into a story, this is just a slightly more complex way of imagining yourself having sex. And who is that woman you –yes you, because the guy doesn’t exist anymore– are having sex with? Just a warm body capable of making you climax. People talk about objectification of women and it’s quite true, but most people don’t really think about exactly how abstract that woman in a porn scene is. Once CGI overcomes the uncanny valley, they will be able to replace actors in porn with 3d models and you will literally not even notice the difference, because the actors weren’t the point.

The Main Problem

Many men claim (and probably many believe) that they prefer women in porn to real women. I would humbly submit this is a lie. “But no real woman satisfies me the way this super kinky porn does.” Sorry, but you are missing the point. Women as seen in porn are vastly inferior to actual women.

shrekdonkeyGet Shrekt

Here comes that food analogy. It was born from a line out of the hit (?) movie of 2001. No, not The Fellowship of the Ring or Pearl Harbor. Not A Beautiful Mind or Hannibal. It was a kids movie. No, not Monsters Inc. Seriously, no guesses?

Yes, it was indeed that classic comedy about an ogre named Shrek.

In the movie, Eddy Murphy plays a Donkey who at one point is trying to cheer up Shrek by comparing him to a parfait, which, he claims everyone likes.

I would assert that, for the purposes of comparing pornographic female sex objects to living breathing women, women are also like parfaits, and the sex objects in porn are like… plain white cane sugar.

Sensual Sugar

Sugar_2xmacroSugar is pretty tasteless when you have it by itself. If you drop a spoonful in your mouth, it initially feels a bit like intensely sweet sand, then that eventually melts away to sickeningly sweet juice. There is no pleasant mouthfeel, if anything the extreme sweetness feels painful on your gums. There are no other accents to the food that is raw sugar, it is just the one intense but lonely note of flavor. By the end of a few spoonfuls, if you aren’t outright sick, you definitely don’t want any more, at least not until that taste is flushed from your mouth by something else. And tomorrow when you are craving something sweet, you will remember the experience as acceptable, but not satisfying. Maybe you will even be driven to wander over to the corner store for something else…

fruit_and_yogurt_parfait_by_cb_smizzle

You know what ELSE everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait.”? Parfaits are delicious. – Donkey

Decadent Desserts

Compare that with a parfait. First up, just look at that culinary masterpiece. It is pleasant to behold. It has texture, color, imperfections that are sure to create variety.

If you take a bite of this dessert, it is a whirlwind of flavors and sensations. There is the initial soft, thick, creamy base. Next up is the hard, salty, oily nuts. Finally there is the firm, sweet, and tart experience of the fruit. And every additional spoonful is layered just as complexly, but each is unique in ratio and order of ingredients. By the time you are done, you wish there was more, and you could reasonably see yourself having one every evening after dinner.

 


 

woman_standingReal Women – Real People

People are imperfect. We are complex, unique, quirky, and sometimes just a mess. But that complexity is what makes human interaction infinitely better than porn. Getting to know a woman as an acquaintance, as a good friend, as a wife, leads to complex interactions of sensations, moods and emotions over time. Sometimes these interactions hurt. Sometimes they even lead to heartbreak when it becomes clear things aren’t working out. But it is the only way to intimately experience another living human, rather than a glorified sex toy.

Exclusivity

If that all sounds like too much bother, by all means go back to pouring dry, bland, single flavor sugar down your throat until you make yourself sick.

But if you ever need a change and are thinking of trying a parfait, first put away the sugar. You don’t need it when there is something better available, and trying to add sugar around the edges of a parfait just masks the flavors that are already there.

Bringing this full circle: the only reason you can say you prefer porn over a girl you are dating is that porn is literally dulling the parts of your mind that can actually appreciate her. So stop blinding yourself with tasteless orgasms, and instead experience the real world in full vibrant color.

Men and Women and (Gay) Marriage

So, I hate to tackle such a touchy issue so soon, but it was the impetus for me actually creating this blog in the first place.

Today George Takei who I follow on Twitter for his outstanding punnitude, linked this image:

A fuller version of this comment is given in this article from the New Yorker circa 2010.

Gay people who want to marry have no desire to redefine marriage in any way. When women got the vote, they did not redefine voting. When African-Americans got the right to sit at a lunch counter alongside white people, they did not redefine eating out. They were simply invited to the table. And that is all we want to do. We have no desire to change marriage. We want to be entitled to not only the same privileges, but the same responsibilities as straight people.

Now, this is an interesting analogy, and one I have heard several times before. The ability to participate in communal eating has nothing to do with the color of one’s skin because the color of one’s skin doesn’t “bring anything to the table”, either in this situation or really any other. It doesn’t affect the outcome of the experience if you have a group of all white, or all black or a mixed group of people dining or voting or working (etc) together. So it made sense to give up racial prejudice and give black people the right to vote and eat and work (etc) in all the same places white people did.

But men and women are different and do bring different things to the table (and I am not just talking anatomically), and “desegregating” various activities has been if anything a harder road here, if less public. It had to be shown that what women bring to the table mentally and ideologically when voting was as good (if not better, on an individual basis) as what men bring. Then the vote was desegregated. It had to be shown that what women bring to the table physically and emotionally when working was as good (again, if not better) as what men bring. Then the workplace  began to desegregate (no woman worker would say that process is over).

Then the question of marriage came up as a small but ever present (as in, around since ancient history) portion of society began to demand equal treatment. I am speaking of course of the homosexual community. By demanding equal treatment and making an appeal to the noble causes of the racial and gender desegregations that came before, the homosexual community is saying that respective genders of two people does not affect their ability to be married together.

This is where I have to draw a line in the sand. Countless books have been written by both secular and Christian authors about what men and women each bring to marriage and how the differences between men and women complement each other. These differences in turn lead to a deeper relationship than one experiences with the closest of friends that one can have with another member of one’s own gender and are part of what can bind a marriage together for a lifetime.

The end is this:

To deny gender differences exist by claiming equality for homosexual couples is to deny the strength that a heterosexual marriage can have because of the differences in the genders.

Now, I could make all sorts of other arguments against homosexual marriage, mostly based on my religious views. But I think that this one stands on its own because it comes right out of what the homosexual community is trying to build their argument from: an appeal to other “rights” movements.