Skip to content

Instantly share code, notes, and snippets.

@kellyvaughn

kellyvaughn/taproom-workflow.md

Created November 11, 2020 20:23
Show Gist options
  • Save kellyvaughn/a1bca1dc9ab96b685d171d6c1ff5bbc1 to your computer and use it in GitHub Desktop.
Save kellyvaughn/a1bca1dc9ab96b685d171d6c1ff5bbc1 to your computer and use it in GitHub Desktop.
Download ZIP
Taproom Workflow
Raw
taproom-workflow.md

Git & Github Process

Git and Gihub provide several benefits to the team and is an essential tool to The Taproom for collaboration and flexibility. Here are some of the guidelines we aim to follow:

  1. Utilize branches - While working on master, branches allow for more collaboration, conversation, and control around changes being made to the code. Commits directly to master should be limited to settings_data updates, client theme updates, typo fixes and emergency bug fixes.
  2. Commit often - The more we commit the easier it will be to roll back when 'that thing we were trying' doesn't end up working out. We believe it is almost impossible to commit 'too often' and encourage commits as often as each deems necessary to benefit their work cycle.
  3. Push often - Similar to committing, it is hard to push to remote 'too much' and easy to do 'too little'. At minimum, we ask everyone to push to remote at each 'stopping point' of the day (ie: lunch, EOD). This allows another member of the team to pick up high priority issues where another left off in case of unexpected sick or vacation day.

Branches

Branching is important to our overall process and organization. A system around branch naming allows us to be organized by connecting branches to feature requests and bug fixes in Basecamp, as well as clarifying who is responsible for a branch.

Our recommended naming convention is [initials]+[todo-title]. A real life example of a name might be jm+email-quote-data-to-customer or jm+update-to-about-page-copy

While this may create long branch names, auto completion for git branches is possible for both bash and zsh shells allowing us to create naming conventions for clarity rather than brevity.

Pull Requests

PRs allow one final step to communicate desired outcomes of a fix and get team member input on code before merging into master. Master should always be the source of truth for what features are live. In case bugs arise, priorities change, ect, we can implement changes on branches based off master without worry non-approved features may sneak in. Here are some other guidelines around pull requests:

  1. When a PR is created, check for merge conflicts and address as needed before getting reviews from the team.

  2. Some choose to rebase and squash, others choose to keep all history. This preference is left up to each developer.

  3. When creating a pull request make sure to link to the Todo on Basecamp the branch is addressing and a link to the Theme Preview (if applicable).

  4. PRs as a general rule, should have a code review and have at least 1 approval before being merged into master. Code reviews have been shown to benefit code quality as much as automated testing. The PR creator can either use the Github UI to request a review or ping specific team members. Ideally, another developer working on the codebase is available to review the PR in a relatively short amount of time, but other team members should be asked if expedience is necessary. Code reviews are not necessary for branches created for settings_data updates or client theme updates.

  5. While not required, descriptive pull requests are recommended and will help reviewers understand the context and the goals for the feature.

  6. Any comments by reviewers should be responded to or have a new commit addressing them by the PR creator.

  7. Once a PR has been reviewed and approved, it should be up to the PR creator to merge the branch into master, unless an explicit request is given to one of the reviewers. As the one communicating to the client, the PR creator will have a better idea when all parties, client and internal team, sign off on the implementation.

Note: Accidents happen. If mistake/change is made and pushed out and a revert is the best option, don’t hold the revert PR. Master should always be our source of truth.

Security

Make sure that any sensitive information such as database credentials, api tokens, user information, passwords etc. are removed from the repository by utilizing some type of external storage mechanism (such as an .env file). If you do commit sensitive information, please make sure to delete the last commit from the remote repository or if there are many commits, deleting the repository and creating a new one with personal information removed.

@mgrafl
Copy link

mgrafl commented Nov 11, 2020

There is a typo in the first sentence: "Git and Gihub [...]" should be "Git and Github [...]".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment