Git Notes

Rebase

You're in working in the repos foo. You're working on a feature branch called beautiful-flower:

git checkout beautiful-flower

You pull requested that branch. Someone did changes on origin/master and now your branch is outdated. You want to update your branch with origin/master.

First, fetch origin, to get all the updates on it:

git fetch origin

Now do an interactive rebase of origin/master on your branch. It will basically take your commits and place on top of the last commits on origin/master, without the useless merge commits of a git merge:

git rebase -i origin/master

Now you can pick the commits you want, squash the commits you want to concatenate with the previous one (or fixup, better than squash when you want to discard the commit message), reword the commits with more beautiful messages and so on.

If something gets into conflict, resolve it, git add the files and git rebase --continue. If you do something wrong during the rebase, don't worry, just do a git rebase --abort and start everything again with git rebase -i origin/master.

After you have completed the rebase, your log should have all the commits from origin/master on bottom and the commits of your branch on top.

Now your branch is update with origin/master. If you want to push those updates to your remote branch, go ahead.

In some cases (when you change the history of your repos), git will say your branch and origin/master diverged and will suggest you to git pull. Don't do that. Do a git push origin beautiful-flower and if it needs to, force it with git push --force origin beautiful-flower. Double check that you're not pushing to master!

Rebase is a powerful tool to tweak commits

Use git rebase -i HEAD~n where n is the number of commits you want to tweak. Now you can pick, squash, delete, reorder, reword and do other little miracles.

It helps us to keep our history tight and readable.

Cheatsheet

Nice one, however I didn't follow it so much:

The slides of author is here.

GitHub flow

• master should be also ready to deployment
• New features should be done in a branch
• You should work on that branch locally and push to it's remote branch continuously
• Branch should become a PR to origin/master when you need feedback/help from someone else or when it's ready to merge
• After someone has reviewed your feature
• After a PR got merged, it should be immediately deployed

Other practices from my own:

• Create an issue to every feature branch
• Create a Trello card to every issue
• Tag your commits when necessary
• Follow semver
• Never use a commit as dependency (only when trying stuff), always use a tagged version
• Add a "WIP:" in front of your PR if you're working on it (not ready to merge)

Partial file changesets

Add -p to git commit and other commands. It will give you the possibility to split your changes ini multiple commits.

Avoid git add -a or git commit -a

Enemy of clean commits.

Never git push --force

NEVER! EVER! EVER!

You should always add git push --force <remote> <branch>!

Git Flow x GitHub Flow

"For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.

For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow."

Undo git reset --hard

Git only cleans cache after days (weeks?). It stores every reference. To list all references:

git reflog

Find the hash of the commit you want to go back and then:

git reset --hard <HASH HERE>

References

• Nice tips on git rebase: http://nathanleclaire.com/blog/2014/09/14/dont-be-scared-of-git-rebase/
• Presentation about git-flow: https://presentate.com/bobthecow/talks/changing-history
• GitHub creator about github flow: http://scottchacon.com/2011/08/31/github-flow.html