Git Fest: April 23, 2015 @ 6:00 pm

New England Software Engineers Meetup 
McGraw-Hill Education, 281 Summer Street, Boston MA
http://www.meetup.com/new-england-engineers/events/221699860/

"Thursday 23rd of April the first Git Fest Night will take place in Boston at the McGraw Hill Education Labs& close to South Station.

"During the event, after an introductory talk we are going to see on the stage folks talking about Git and its usage from different perspectives.

"In the introductory talk Aslihan Uzun will present a look at the unique aspects of Turkish culture and related issues in New England, and her perspective on the lives and community of people of Turkish heritage.


"Food and beverages will be in line with the culture introduced during the event".

We will bring you coverage of the event, but first a word from GitFest's sponsors:

• Maximillian Alexander flew in from San Francisco to talk briefly to us about his app, Epoque ( https://epoqueapp.com/ ) which just was released to the Apple's App Store today. Participants could download his app and use it to chat with other audience members in real time in a chat room "Git Fest" that he created for this talk. If you download it, he mentioned, make sure to accept to share your location. To view some of the messages people sent, you can go to https://epoqueapp.com/worlds/5537703fb2ec789e281f7fff

• A guest speaker who worked at McGraw Hill, Sierra Koral, talked abuout how the date of the Meetup, April 23, was of great significance to the Turkish People. It was National Sovereignty Day. She talked about Mustafa Kemal Ataturk, the founder of the Turkish Republic. The date was also National Children's Day, since Ataturk dedicated the Turkish Republic to the children. Children's festivals take place all day, and Turkish schoolchildren take seats in Parliment. In honor of the day, they had the event catered from Boston Kebob House. 

The fact that the @Meetup event I am attending tonight is called "GitFest" makes me giggle. http://t.co/otd1wDQ5MC #nese #git
— T.J. Maher (@tjmaher1) April 23, 2015

A Bit about Git

Here's what I picked up through independent research: 

Git is a software configuration management tool written as part of the Linux project back in 2005. It allows a team of software developers to work together. You can checkout code from a master branch to your local machine, such as the MacBook where you are developing code. You can pull any changes to the master branch down to your development workstation creating a local branch on your machine. You can commit your changes to the master branch, adding comments on what code you changed and what bugs the commit fixes. After the code has been reviewed, you can attempt to push the changes to the master branch, and hopefully there will not be any merge conflicts. When developers do a pull from the master onto their machines, your code changes will be displayed. People can look in the Git history to see what was changed and when, tracking the life of the software project.

On to the first speaker! 

Practicing Git

Zach Shaw,
Organizer, Boston Software Craftmanship
Principal Software Engineer for Brightcove
[ LinkedIn  | Blog | Twitter: @zdsbs  ]

The first speaker was Zach Shaw, from the Meetup.com group, Boston Software Craftmanship, also known as Boston SC. Boston SC is a monthly group that has been around for the past four years. Its mission is to host sessions so that software engineers can improve software development skills through practice.

But why practice? And why practice Git?

Engineers want to practice, but aren't sure what to practice, so these sessions have been set up as a guide. Practice sessions are usually two hours in length. Typical Boston CS sessions run around 10 to 20 attendees at a time and can scale up to 30. And by "practice", Zach told the audience, he meant going through an exercise just for an educational purpose. The problem is that with a job doing software development, you can't really experiment. What they work on during the practice sessions is is something you can delete afterwards. There isn't the pressure programming on the job might bring.

Zach asked a few rhetorical questions to the audience: What is Git? Do you really know what it is and how it works under the covers? Can you get Git to do what you want? Do you know what your SCM (Software Configuration Management) messages should be like? What is your Git philosophy? When do you use Git? When do you merge your code into the master branch? What makes a good branching strategy?

"Git is all about communication. What does your Git commits tell you as a story"?

Zach described a Messaging Exercise in Git he used in a practice session.

From the Messaging Exercise site: 

"In this coding exercise, you gradually evolve an application for sending two different types of messages, emails and IM chats, through a network connection. The mechanics of input and output are drastically oversimplified (command-line input, and output to one single writer that represents different network connections), but are just realistic to simulate some of the issues that a real app would face. There are a series of end-to-end tests representing eight different user stories. All but the first are annotated with @Ignore. Once the first story is complete, remove the @Ignore from the second and start work on it, and so on".

Zach mentioned in this practice session, people worked with this exercise in teams of three, trying to produce what they thought was the idealized git history. They also tried to figure out what they could do within an hour, then compared notes on how much they got off course. How big the commits should be and how small.

Zach ended that section by asking the audience:

"The question is... what is your ideal git commit history, and what is your git philosophy"?

With the next section of his talk, Zach talked to the audience about how they could map out the Git process and history using a Directed Acyclic Graph, a way to model information.

... I found a chapter the next day describing Directed Acyclic Graphs in the online text Version Control By Example (2011) by Eric Sink.

Zach gave a new challenge to the audience: How fast can you be just manipulating the DAG? He introduced a multimedia course called "Learn Git Branching" at http://pcottle.github.io/learnGitBranching/ by Peter Cottle. 

"LearnGitBranching is a git repository visualizer, sandbox, and series of educational tutorials and challenges. Its primary purpose is to help developers understand git through the power of visualization (something that's absent when working on the command line). 

"You can input a variety of commands into LearnGitBranching (LGB) -- as commands are processed, the nearby commit tree will dynamically update to reflect the effects of each command." ( README, LearnGitBranching)

Zach said these were exercise to run with a group. Group coding exercises are fun to do, he said.  And after the exercises, he would ask participants: Did you get more facile with the DAG? Did you learn more Git commands? People enjoyed improving areas of software engineering.

Zach invited everyone to check out Boston Software Craftmanship. They are on Meetup.com: http://www.meetup.com/Boston-Software-Craftsmanship/

Their next Meetup, April's Boston Code and Cocktails ion Tuesday, April 28th in Central Square, Cambridge. I need to check them out! I wonder if some fellow Fitbit developers might want to walk over to check it out with me? I need to to remember to ask around the Boston office... I earned my degrees a bit under ten years ago but haven't really coded on the job until now. I have a lot of catch up to do! 

Pardon me as I run around like a cat whose tail is on fire.  

Oh! The next lecturer is coming up...

Three ways are better when merging

Stephen Vance
Director of Agile at Zipcar
Co-organizer, Boston Software Craftmanship
Co-organizer of NESE
[ LinkedIn | Site: Vance.com | Twitter: @StephenRVance  | GitHub ]

... By the way, Stephen mentioned, Zipcar has openings.

Three-ways are better (when merging) from srvance

Merge is panic inducing for people. 

Out of the box, the only give you out of the box, diff --git which is text only and can be very hard to read. There is a GUI you can use, though, by Perforce called P4Merge that you can download. It is a better three way merge tool.

1. Download and install P4Merge
2.  Add it to your path, such as with a Mac:

export PATH=${PATH} :/Applications/p4merge.app/Contents/MacOS

3. Configure git to know about it.

git config -- global merge.tool p4merge
git difftool --tool-help

4. Use it

git difftool some.txt

Back in the console, you might see messages mimicking what you are doing in the GUI. You can turn that off:

git difftool --no-prompt some.txt
git config mergetool.prompt off

You need to remember to set up the mergetool, not just the diff tool:

git checkout master
git merge other // where "other" is the name of a branch in this example.
git mergetool

Steve mentioned that he has seen online how people are setting up shell scripts to tell the tool where the tool is located. You don't need a shell script, just set up the path.

Once that is done, you can see three way merges, three panels.

Let's say you do in the Terminal window of your MacBook: git status and get back that there is a merge conflict. You can start the merge tool by git mergetool.

Let's say you have "The quick brown fox jumped over the lazy dog" and you are missing an s at the end. You can compare the three panes. You can pick the original in the first pane, or the edit in the middle, or both in the third pane. Now run:

git status

Merge conflict is resolved. You can do your commit and your merge is done. Much better insight to your merges.

In the Q&A session, some people asked about using IntelliJ. Steve mentioned IntelliJ is still a 2-way tool even though it is better than other 2 way merge tools. Steve mentions if he is already developing with it, he uses their built-in feature for simple merges. Complex merges, Steve drops out and uses PForce. The basic commit / add / edit workflow, it contained in IntelliJ. When he is using the Sublime text editor, he usually doesn't do commits with Sublime's built-in features, and he just drops down to the tool. Simple merges he also does with the command line.

Git is History: Using the history for fun and profit

Kenneth Sebesta
Senior Controls Engineer at CyPhy Works Inc
[ LinkedIn ] 

Ken started off his talk on Git mentioning how he uses Git... It isn't the best way, but it is his way. There is a lot of ways to use Git. Some of his stuff works for him, on his own. His way though is brittle. He is continously doing ten merges in a row and having it break. "Weird integration issues. Not very fun".

"SCM (Software Control Management) is all about history. Why don't we use it all the way? Atomic commit. Thinking about the future, picture yourself looking at the code five years form now".

Ken presented a quote from Peter Hutterer, a software engineer at Redhat, taken from Peter's essay, "On Commit Messages"  12/28/2009

"Re-establishing the context of a piece of code is wasteful".

Ken metioned that Git commits should be atomic. If you have two features, split them in two separate commits. The most atomic commits possible.It is challenging, to make atomic commits while code is being modified. The problem is that the whitespace fixes, the style fixes, they all get jumbled up, and it is difficult to track later what happened with the code change.

Ken told the audience: Use a GUI. Don't be stubborn. Git comes built-in with a tool, Git-Gui http://git-scm.com/docs/git-gui. It is the same across platforms, whether they are Mac, Windows or Linux.

• If there is difficulty in separating things out because it is two different ideas, use two commits.

The two minutes you spend now will save you thirty minute in the future trying to figure out what the commit did in the first place. When you are hunting a weird interaction bugs interoduced in a merge, you wil thank yourself.

• Label broken code as ***broken*** or ***untested***.
• Be verbose. You are writing history.

When you think about it, the Who, Where and When of a change in the code is taken care of when you use Git. You just need to take care of the Why.

Why did you make your change? Was something broken? Describe the broken functionality. It is educational for the people who follow you on GitHub. Describe the fix.

"Describe the What: Explain the change. Not everyone is familiar as you are. Provide as many links to the subject as you can. Provide deep link when possible so that people don't have to guess why it is being used. Don't use shallow links".

What does a good commit message line look like?

• The first line should be short: 50 characters or less, almost like a Book Title and a subtitle, such as: Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb
• Leave a space
• In the body use a newline after approximately 72 characters wide. If something goes past the edge like a long URL it is okay, they aren't sticklers.

What tools does Ken use when doing Git?

• GitHub 
• GitK, the Git repository browser built into Git. 
• GitLab, a tool that bills itself as "Better than GitHub".  

Ken mentions that Git styles are cultural. 

No approach is perfect but just like a coding style guide, it is good enough for 99% of the cases. 

How important are good commit statements? 

Ken believes that during code reviews, you need to check to see if the person's code you are reviewing have good descriptive commit messages. If it doesn't have a good commit message, you should fail the code review.

An example of a good commit message:

Ken went to angular / angular.js on GitHub. he observed that there were over 6,000 commits to the codebase.

An excellent version of a commit statement would be:

With this commit message, you can tell by the commit header, the commit description, you know exactly what code was changed. You even have links to the bugfixes.

Remember that commit messages track change. The changed could be major refactoring. You don't know the product or maybe even the language. All you have to go by is the commit messages. 

How do you decide if you are going to merge something into the master? You need to decide should you merge the person's change into your open source product. 

Do merges frighten Ken? 

No, Ken is not scared of merges, he says, because he rebases everything! ... then he laughed like, "Heh-heh-heh". 

Unsure why rebasing would be bad, I searched on Google using the search terms: "don't use rebasing":

• Please, stay away from rebase - OneAndOneIs2

• Don't Be Scared of git rebase - Nathan LeClaire

• Why you shouldn't use git merge --rebase

• Thou Shalt Not Lie: git rebase, amend, squash, and other lies

Ken's argument is that people shouldn't see the sausage being made, all the minor typos that happen. You can rebase it back down to remove from the history al the silly typos you make. Do git commits just with the main functionality. 

How he described it: Imagine if you take a chunk of code, a pyramid, and you only want the top half of the pyramid.  You can grab the top layer of the pyramid you want to keep, and slide a whole other pyramid  section underneath it. 

You can say: Take this whole branch and swap it out onto another history.

Rebasing is good for you. It shows a carefully cultivated history. If you are doing nothing more than fixing whitespace, he recommends adding a message such as "fixed style changes".  Do one commit for tidying up the whitespace, then another commit for the actual code change. But if you goofed up, forgot an #include statement, just rebase. 

Ken mentioned that that his company CyPhy works is hiring. He can be reached on http://lu.linkedin.com/in/kennsebesta

Related links:

• If you want to read all about Git, Scott Chacon and Ben Straub have released their book, "Pro Git" for free at http://git-scm.com/book/en/v2

-T.J. Maher
 Sr. QA Engineer, Fitbit
 Boston, MA

// Automated tester for [ 1 ] month and counting!

Please note: 'Adventures in Automation' is a personal blog about automated testing. It is not an official blog of Fitbit.com.