owned this note   changed 4 years ago  
Published Linked with GitHub

Northstar GitHub Practices

Git Workflow

Feature & Bugfix Workflow

  1. Create a feature/bugfix branch off of main
  2. Commit changes to feature/bugfix branch
  3. Open PR from feature/bugfix branch into main
  4. Ensure CI is passing on feature/bugfix branch
  5. Squash and merge PR into main
  6. Delete feature/bugfix branch

Release Workflow

  1. Determine version to release (major, minor, or patch)
  2. Run the GitHub Actions release workflow
  3. Follow up on JIRA and GitHub Issues that the release addresses

Branch Naming

  • Title with a short description
  • No branch grouping or prefix pattern in branch name

Pull Requests

PR Template

PR templates will include the following:

  • Jira ticket number
  • Why was the change made?
  • Description of the change
  • Any relevant code snippets
  • Manual testing steps and test data to allow other developers to easily test the change
  • Screenshots / device recordings / gifs of UI changes

PR Reviews

  • 2 reviews are required for merging in a PR
  • The developer who opened the PR should push for getting reviews.

Merging

  • PRs going into develop will be squashed and merged.
  • Release PRs going into main will use a merge commit.

Commits

Commit Messages

When merging in a PR, the squashed commit message will include:

  • Jira ticket number followed by a command-style language title
    • For example, your commit message can be read off as a command to the computer to execute a task. Example: "Add CHANGELOG entry for v5.4.1" or "Remove dependency on PPRiskMagnes for BraintreeCard in Package.swift file"
  • Use git-duet to co-author commits

Updating Local branch

When pulling in the latest changes into a local branch, use a merge and not a rebase.

Release Tags

Style Guides

Maybe for each platforn we can come up with style / syntax guides that we want to follow for use throughout. We could start this as we start dev work. - Sammy

I really like the idea of a style guide! This would also be a great place to have some of the information in this doc once we finalize things since the project will be public it'd be great to have things documented for outside contributors. - Jax

I love the idea of having a style guide. On Android, we were looking at using Detekt as a static code analysis tool. It'll definitely be worth adding some documentation on how to use this tool along with the rule set that we're enforcing. - Tim

Archived Discussion

Branch Workflow

Options:

  • Feature branches off of develop
    • Customize deployments of develop and main branches (snapshots)
  • Feature branches off of main

I am a fan of having both develop and main branches since we could theoretically use git hooks to produce SNAPSHOTS from develop and releases from main. -Steven

Maybe we could consider forks for active development, instead of everyone working directly off of main / develop? Our main repo could consist of just main / develop and then maybe larger feature branches that we could PR to as well - Jon

  • Hotfix branch off of Main

Would we rebase develop onto main once a hotfix is merged? -Steven

Branch Naming

  • Do we want to have a branch groupings/prefix pattern?
    • feature/[BRANCH NAME], bugfix/[BRANCH NAME], hotfix/[BRANCH NAME]
    • branches grouped by developer: tdchow/[BRANCH NAME]
    • branches grouped by jira ticket [JIRA TICKET]/[BRANCH NAME]

I'm personally indifferent here. I did see a gnarly bug once in one of our bash scripts though where a branch with '/' caused a script to bug out after paramater expansion. -Steven

Similarly indifferent here. I think we typically follow the first one for the most part on the PayPal iOS side. Would love to have a clearly defined way to name these though. I know on the iOS side some folks use bug vs bugFix and it would be nice to be consisient. Could also be something we add to a future style guide / development guidelines. - Jax

PR Reviews

  • How many reviews are required to merge a PR?

i think 2 is enough
Do people feel comfortable reviewing PRs in both the iOS and Android repos?

  • Do we want to set an expectation on how soon PRs will be reviewed once they're opened?

i wouldnt, i think its the developer's responsability to push for review

Merging PRs

  • How do we want to merge in PRs?

    • Merge commit
    • Squash and merge

    I vote for squash and merge.
    * This makes reverting the PR, if need be, much easier.
    * It makes sifting through commit history easier to read. - Sammy

    • Rebase and merge

Rebasing vs Merging

It will be helpful to keep this consistent. I like merging more since it makes reverting much easier. It also just simpler IMO. - Sammy

Select a repo