Git Strategies

This project mainly uses the gitflow branching strategy. A guide for this strategy can be found here.

In combination with this strategy sometimes it's helpful to rebase your branch before merging your pull request. This is useful for squishing commit history (this way we don't get "fix pr issues" commits in the central repo), updating your local branch to be at the end of develop (helps to create a sawtooth git history), and removing/changing any commits in the past that you want.

The general workflow I have used for this is:
From dev
git checkout -b "ticket#-new-feature-branch"
work on your branch and create your feature, committing as needed.
When done, push your branch to the repo for a PR.
git push (likely have to set the upstream to origin branch-name)
Make the PR on GitHub, get feedback, make changes and push
When the PR gets approved and you're ready to merge it:
git switch dev && git pull -> switches you back to develop and pulls to update it to the newest version
git switch - switches you back to your previous branch (can also use git switch [ticket#] - new-feature-branch
git rebase -i dev rebases the feature branch onto the end of develop (in interactive rebase mode).
In the menu that pops up, pick the top commit, and squish the others into it. You can also pick others if it makes sense to have them as separate commits. \

• If there are merge conflicts, you'll have to go through them, resolve & stage the changes, then run git rebase --continue

After successfully rebasing you should have 1 commit that contains all your changes. To push them up to the repo use:
git push --force-with-lease
Merge your pull request and delete your feature branch from origin (GitHub repo)