That's how we get a bunch of noise on the commit log.
same style as nodejs or expressjs collaborative git style
lets run through an example workflow and of merging a branch called ayyyeeee
# start out in master or whatever destination branch and make sure it's not borked
git checkout master && git pull # you could also do: git fetch && git rebase
# make sure everything on the branch is kosher and up-to-date
git rebase
# now lets move into the branch we want to merge
git checkout ayyyeeee
# assuming we're merging to master, ensure the branch is up to date (ahead of)
# destination branch. this will replay any new commits here directly on top of
# commits in master for clean linear history. do this all damn day, every day!
git rebase master
# also btw to break out of any borked rebase state:
git rebase --abort
# sometimes its nice to just run git rebase --abort first before doing rebase
# if we need to squash any extra commits
git rebase -i master
# else if no squash, time to --amend. on a new line, note the PR #
# • PR: #7
git commit --amend
# doing amend also gives credit to the reviewer on github "committed with @so-and-so"
# list issues that get fixed so github can auto-close them
# https://help.github.com/articles/closing-issues-via-commit-messages/
# both squash and amend changes the commit hash locally (not for remote branch)
# since we changed hashes we'll need to force push that new info up to branch
git push -f
# now github/bitbucket can pick up the merge with a correct (updated) commit hash
git checkout master
git merge ayyyeeee
git push # boom! done.
# one last point to consider
# throughout your workflow it's a really good idea to run:
git log # just to sanity check wtf's going on in the branch history
git show # to see a diff of the last commit... to go back further use:
git show -10 --pretty=medium