In this episode, Ben and Joe ship a feature from start all the way into production.
For more info, check out:
The actual pull request and commit in the Learn codebase. Our protocol for getting things done, The parity gem and Travis, our CI provid...
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/ship-a-feature
@benorenstein @jferris I really like this episode, since it shows the end to end of writing a feature. But it is a “backend” feature. What do you guys think of doing the same thing for a “frontend” feature.
The main points I would like to see focused are designer/developer communication and hacks/compromises made when writing Sass.
Keep up the good work.
Great episode!
For anyone who isn’t already familiar, the tool for creating pull requests on the command line is the hub gem.
A question for Joe and Ben: Why do you prefer to merge into master on the command line rather than on GitHub?
BTW, the link to the parity gem in the episode page is pointing to Travis CI.
Most of us have moved from hub to gh, which you can find here: GitHub - owenthereal/gh: Fast GitHub command line client (deprecated). gh has been merged into https://github.com/github/hub, see https://github.com/github/hub/issues/475 for more info. It’s faster and not a gem (so you don’t have to keep it installed in all of your rubies).
[quote]A question for Joe and Ben: Why do you prefer to merge into master on the command line rather than on GitHub?
[/quote]
The big green merge button on GitHub creates merge commits in your history. We generally prefer a clean, straight-line history and ensure that by rebasing and merging locally.
I have few questions:
- Do you guys usually put story id and story url that links back to your issue tracker?
- Do you setup your staging server on heroku to run on production environment or staging environment that you created another file under
config/environments/staging.rb?
I typically do not. Issue trackers come and go, but my git history is forever. I try to put as much pertinent detail in the final commit as possible. If there’s significant discussion in the issue tracker that impacted the implementation, I will try to boil that down and perhaps link to it for full context. In general, I think it’s a bad idea to rely on a git → issue tracker link to communicate.
It runs in staging mode with a staging configuration but that configuration first requires production. Then we override from there. See: https://github.com/thoughtbot/suspenders/blob/master/templates/staging.rb
I usually add the link to the issue tracker on the pull request message, but not on the git commit message, for the same exact reason.
I’ve tried gh and found the pull-request command to be far inferior to hub’s. Namely, it did not open on my editor with the commit message as the pr message, if there is only one new commit. Have you guys experienced this, or is it just my config that is incorrect?
I have not had the issue with gh that you speak of except when my local master is behind origin/master when I run gh pull-request. The command builds the PR based on what you have locally in master so in that case it thinks there are two commits in the PR.
Not sure if this was also an issue in hub or not.
I made a branch with one extra commit from the master branch, trying to create a pull request from hub looks like this:
Better JS code
# Requesting a pull to zamith:master from zamith:zh-test
#
# Write a message for this pull request. The first block
# of text is the title and the rest is description.
While in gh I get:
# Requesting a pull to zamith:master from zamith:zh-test
#
# Write a message for this pull request. The first block
# of the text is the title and the rest is description.
The commit message is “Better JS code”.