Illustration by Christine An
Illustration by Christine An
We are in the homestretch with our git workflow walkthrough. I knew we could do it! Last time, we looked at a few ways to review pull requests. In this final (for now!) installment, we will merge our reviewed changes back into
Once your pull request reviewer is satisfied with the changes, you’ll get the coveted
+1 (or equivalent affirmative emoji), which means it’s time to get this thing merged!
In many cases, a visual check of the changes via the PR page on GitHub is enough to give a +1 to changes. That’s how we did things in our previous walkthrough post.
Last time, we looked at how using feature branches makes life easier, and how you would create a feature branch to make a change and push it up to GitHub for review in the form of a pull request.
Now that a Pull Request is live, someone has to review it. Let's walk through some of the steps involved in making this process go quickly.
When it comes to learning Git, most folks I've talked to (myself included) have taken the slow and gentle path toward becoming proficient by adding it incrementally to their existing development processes.
We begin by just running
git init on an almost finished project and adding everything with a commit message such as
start. Then, we learn a bit more about good commit messages and chunking up changesets. Collaborating through GitHub and merging comes next.
We build a lot of software at Bocoup. Like other types of builders, we tend to grow attached to the particular sets of tools and scripts we use in our work. We don't play favorites: my colleagues support Grunt, contribute to Gulp, and maintain stand-alone tools such as JSHint. It's easy to take familiarity with these tools for granted, but for our clients (or new project contributors) every new tool is another barrier to entry.
Look, I like good typography as much as the next person—maybe even a little more. When a CSS property came along with promises to doctor all my type with ligatures and carefully calculated kerning—not some half-assed tracking, but real kerning—I jumped at it. I put
text-rendering: optimizeLegibility on headings, body copy, navigation links; I slapped it on images just in case a ligature might appear in the background of a photograph, blurred, like an aesthetically satisfying poltergeist.
As Bocoup has grown, we've started using new tools to manage information internally. We wanted a company Wiki, but which one to use? A new "Bocoup Meta" repo in GitHub with a Wiki ended up being a good choice. What we didn't realize yet was that the Issues in that repo were going to become just as important.
I'm honored to have been named lead maintainer of JSHint. Following in Anton's footsteps, I'm excited to carry on his vision for the project and see it forward. In addition to overseeing regular maintenance of the project, my primary goal will be to prepare JSHint for ES6. Stewarding this work will be an exciting challenge, however not one that I plan to take on by myself. Thankfully, everyone at Bocoup shares a strong preference for well designed, consistent, and reliable code by promoting and practicing the use of robust developer tools. As a team, we're excited to be part of this project, and look forward to working with the community to see it grow.
CSS is awful, but it doesn't have to be that way. For example, new languages that compile to CSS like Stylus, Less, and Sass have made it much less painful to lay out and style web projects. However, these projects are limited: they provide delicious, delicious sugar, but ultimately they are using the same core semantics as CSS. I am really interested in projects that replace the semantics of CSS with something brand new and wholly better: check out Grid Style Sheets, for example. Someday websites might be designed with something like GSS instead of CSS.