Skip to content

Instantly share code, notes, and snippets.

@t-lock

t-lock/git-workflow.md

Last active December 5, 2024 03:30
Show Gist options
  • Save t-lock/1ee1d8ed02af39036a7e9a1c8bf3c862 to your computer and use it in GitHub Desktop.
Save t-lock/1ee1d8ed02af39036a7e9a1c8bf3c862 to your computer and use it in GitHub Desktop.
Download ZIP
AoB Git workflow for contractors
Raw
git-workflow.md

Note "The main branch" in the following text refers to either "master" or "develop" depending on the project.

  1. Start your feature branch from the latest on the main branch.
  2. Make commits along the way which represent cohesive chunks of functionality. This can be a single commit for a feature, or multiple commits if necessary. Please utilize git commit --amend and or git rebase HEAD~<n> -i to keep history clean and orderly to the best of your ability.
  3. Rebase off the main branch frequently to make sure you are getting upstream changes. Ex: git fetch && git rebase origin/master -- Fix any conflicts as they arrive during this process.
  4. Open a PR when the feature is ready, but always rebase again before making the PR.
  5. If changes are requested: make the changes and rebase again (there will often be new work in the main branch after code review, because we code review multiple PRs at the same time, and some will be merged). Note: A force push may be required to get the new changes up to your feature branch on origin at this point, and that is perfectly normal. As the author of a feature branch you "own" that branch and can force push to it as you see fit, as you are only overwriting your own work with a more proper commit history.
  6. When a PR is approved, we will merge it into the main branch and delete the feature branch. The work is now available for other developers working on feature branches to get when they rebase off the main branch (your work is now "upstream" to all new branches).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment