Raymond Brigleb brigleb

Why We Use Git

In the past, we kept files on disk and maybe backed them up. It might be impossible to recover anything useful ever.
Then we started using Dropbox. This was nice because each file got a linear history. Better.
With Git, you get a snapshot taken of your project whenever you want, as much as you want.
You can also use branches for multiple timelines, which lets you write better code because you are safer.
Git also provides features and integrations designed to make your life easier if you work with this stuff all day long.
We want to keep as much stuff as possible checked in when working on a project, including style guides, documentation, requirements, non-massive file assets, etc.

Git Principles

User stories

In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard.

http://en.wikipedia.org/wiki/User_story

Product backlog

The product backlog is an ordered list of requirements that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product.

These are the things I typically set up on a new Mac to make it a bit more pleasant. Basically from the command line.

Install Xcode and its command-line tools.

Generally I just do this from the App Store.

https://itunes.apple.com/us/app/xcode/id497799835?mt=12

Install Homebrew, and some apps

GitHub-Assisted Web Development

GitHub is a great tool, and while our developers use it extensively when building out websites, its usefulness is magnified when everyone on the team is using it. We don't expect everyone to necessarily check in and out code, but there's a lot more to GitHub than that.

Issues

Issues in GitHub are like discussions in a project management system like Basecamp, although they wrap a ton of features into one bundle. Issues can be treated as simple checklists, or they can contain checklists within themselves.

They are formatted using Markdown, which our team knows from using many other tools.

Git and GitHub Learning at Needmore

This is "course plan" for a very informal set of videos, discussions, and resources for getting better at using Git and GitHub at Needmore. We're spending an hour a day, one day at a time.

Largely, we're basing our conversations on the Lynda.com videos which are excellent. Our development process in our Notebook is obviously essential reading.

Day 1: Monday, February 24

Intro: Why are we doing this? (To have a solid foundation, ensure we're using the same process, and answer lingering questions)
Chapter 4: Git Concepts and Architecture

Tips for using Git and GitHub

Git repositories should be named after the domain name of the project. If that's not possible, get as close as you reasonably can. The best name for www.masusushi.com repository is probably masusushi.

The master branch should always contain production-ready code. It should be ready to deploy to the server at any time. If someone else wants to deploy, all they should need to do is run it through a preprocessor that supports Compass (like CodeKit).

If we have a staging server in use, also use a dev branch which corresponds to that server. If we just have a staging server that will sort of become the actual server, don't worry about it. In that case, just using master is a-ok.

When you deploy, tag that commit. If you're deploying to production, deploy from the master branch. If you're deploying to staging, deploy from dev branch. When you merge to master (and dev), you should deploy right away. A very good time to tag and deploy an active project is at th

	// Breakpoint mixins
	@mixin bp($point) {
	// assume that the default is 'small'
	// usage: @include bp(large) { ... }
	@if $point == medium { // 641px, 1024px
	@media only screen and (min-width: 40.063em) { @content; }
	}
	@else if $point == large { // 1025px, 1440px
	@media only screen and (min-width: 64.063em) { @content; }
	}