A guide for completing a feature using version control and Trello.
Project Management
Next Up
- Prioritized list of all cards vetted and ready for design & development.
- It’s worth noting that as a engineer or designer you’re not required to take the top card off the stack but rather the top card you feel most apt to handle.
In Progress
- These are the cards that are under active design or development.
- Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
- When an engineer takes a card they assign a due date on it to let others know the “expected” delivery date of this card to QA. A quick scan of our board tells me that this rule is more aspirational than executed upon. :)
Code Review
- When an engeneer thinks they've completed the story, they'll ask for a code review via slack. They will create a pull request so that another reviewer can look at the code. Pull requests can also be used for asking questions and reviewing code
QA
- The engeneer will deploy to development (or send a build out to the internal team for iOS/Android) and drag the card to QA. At this point it our QA manager and they'll test the new feature
Launchpad
- These cards have been reviewed by QA and are ready to be deployed (but not necessarily launched, but more on that in a minute) and there’s probably a GitHub Pull Request associated with it (which will be merged into master by the person that opened the pull request. It’s worth noting that there is no central chokepoint for merging into master: everyone can do it).
Live (Week#)
- These cards have been deployed and are no longer hidden behind feature flags.
- The only people who move cards to “Live” (essentially our Completed list) are the Product Manager (for enhancements) and the Bug Reporter (for bugs). This helps ensure that the feedback loop is completed before cards move out of sight.
- Each week has it’s own Live column so we can track what got launched when.
- Avoid including files in source control that are specific to your development machine or process.
- Delete local and remote feature branches after merging.
- Perform work in a feature branch.
- Rebase frequently to incorporate upstream changes.
- Use a pull request for code reviews.
Create a local feature branch based off master. Write unit and integration tests first!
git checkout master
git pull
git checkout -b <branch-name>
Rebase frequently to incorporate upstream changes.
git fetch origin
git rebase origin/master
Resolve conflicts. When feature is complete and tests pass, stage the changes.
git add --all
When you've staged the changes, commit them.
git status
git commit --verbose
Write a good commit message. Example format:
Present-tense summary under 50 characters
* More information about commit (under 72 characters).
* More information about commit (under 72 characters).
http://project.management-system.com/ticket/123
If you've created more than one commit,
use git rebase interactively
to squash them into cohesive commits with good messages:
git rebase -i origin/master
Share your branch.
git push origin <branch-name>
Submit a GitHub pull request.
Ask for a code review in the project's chat room.
A team member other than the author reviews the pull request. They follow Code Review guidelines to avoid miscommunication.
They make comments and ask questions directly on lines of code in the GitHub web interface or in the project's chat room.
For changes which they can make themselves, they check out the branch.
git checkout <branch-name>
./bin/setup
git diff staging/master..HEAD
They make small changes right in the branch, test the feature on their machine, run tests, commit, and push.
When satisfied, they comment on the pull request Ready to merge.
Rebase interactively. Squash commits like "Fix whitespace" into one or a small number of valuable commit(s). Edit commit messages to reveal intent. Run tests.
git fetch origin
git rebase -i origin/master
Force push your branch. This allows GitHub to automatically close your pull request and mark it as merged when your commit(s) are pushed to master. It also makes it possible to find the pull request that brought in your changes.
git push --force-with-lease origin <branch-name>
View a list of new commits. View changed files. Merge branch into master.
git log origin/master..<branch-name>
git diff --stat origin/master
git checkout master
git merge <branch-name> --ff-only
git push
Delete your remote feature branch.
git push origin --delete <branch-name>
Delete your local feature branch.
git branch --delete <branch-name>