* Extract Git, Rails, and iOS protocols. * Move Rails-specific code review to Rails protocol. * Make git protocol less Rails-specific (instead of `rake`, say "run tests" so it can continue to apply to iOS, Haskell, etc. projects). * Nest bullets. * Use consistent capitalization.
* Removes short URLs * Makes it easier to see what you're being linked to * Improves readability by removing long, inline URLs
* Prevents wrapping long list items, improving readability * Removes the need for short URLs
Functional changes: * Don't forget to fetch before rebasing. * Change Thin recommendation to Unicorn. * Remove `--rebase` due to discussion [here](thoughtbot/dotfiles#111). Improvements for better readability/documentation: * Replace `<>` style code comments with sentence instructions. * Use full options flags (`--verbose`, `--delete`, etc.) for clarity. * Use `<branch-name>` consistently (angle brackets and `-name` suffix).
* Attempt to keep styles as conventions, formatting, organization * Move workflow rules into protocol * Move practices that go beyond formatting into best practices
Since GitHub introduced [relative links in markup files](https://github.com/blog/1395-relative-links-in-markup-files), links with absolute paths such as `/thoughtbot/guides/blob/master/...` will no longer work.
* Create a connection between project management system and git history. * Make it easy for future developers to understand the reasons why code exists without having to disturb the original author or relying on the original author being available/on the project/not sick/not on vacation/ with the company at a later date. * It requires little effort (10-20 seconds) to add the link. * It encourages a ticket/story for commits. #40
Asychronous code review via Github pull requests can be incredibly efficient, but easy to accidentally offend or miscommunicate if we aren't careful about our language choices or have a common expectation of how to act when reviewing and responding to reviews. This new guide attempts to set some basic expectations to streamline code reviews and help us stay happy, healthy, and working closely as a team. * Distinguish between discussions that are appropriate for code reviews versus those that are appropriate for technique discussions. * Include simplicity as a goal. * Summarize offline conversation. * Show, not tell, how to link to project management system ticket. * Clarify sign off.
* Allows ignoring binstubs without ignore bin for gems
* Add iOS to Best Practices * Add iOS to Style Guidelines * Add iOS to Protocol * Add sample Objective-C code
* Create "protocol" and "best practices" guides. * Add belongs_to validation guideline. * Remove "Always be learning" non sequitur. * Move Heroku remotes to "protocol." * Remove `Procfile`. It is in `suspenders`. * Remove Cedar. It is the current Heroku default. Creating an app using `suspenders` per the "protocol" guidelines will do this automatically. * Move move-out.md to best-practices/README.md. * Flatten `.env` example code block. * Improve squashing guideline. * Separate "Merge" and "Deploy" sections.