We’ll be using Github as the source repository. You’ll be added as a team member, so you won’t have to fork.
Create branches starting with the Github issue number all using lower kebab case, something like 101-create-app-specs
Master branch is the latest, and you would clone the latest master to a feature branch locally.
You are working on writing specs for this branch, and have committed say 5 times. No changes are pushed yet.
master branch was updated and there are some code you need, what would you do? Your first instinct may be to issue git merge master while on the feature branch.
But using merge is not a good practice, as it messed up the history and does not keep a linear commit history.
Instead, we want to update our local master branch to the latest commit by calling git fetch origin master:master, then issue git rebase master.
By rebasing, we are putting the new changes before our new commits. The last step would be to force push to overwrite the remote branch, since we have re-written the history.
You should rebase as often as possible, whenever master has new changes. Putting it off will mean you’ll have to deal with it later down the road, and the memory of your changes may be less clear.
Sometimes, you’ll be greeted with many merge conflicts that you’ll have to resolve. This is usually a sign that either you have gone too long with a rebase.
If you have many commits, say more than 5 (roughly), it may be better to perform a squash on your local branch, which could combine all your commits into a single commit.
By doing so, during the rebase process, you’ll only have to resolve merge conflicts once. Keep in mind that you do lose some commit information, so you'll need to keep in mind of the trade-off.
Once you are completed with the issue: