Over the years that I have been using Git I gathered quite a few useful links. As at work we made the switch from SVN to Git recently it seems to be the perfect time to finally share some of these links on my blog. There are, of course, the man pages, the “official” book and reference. These are undoubtedly good resources but they are very thorough and therefore a bit dry and more suitable as a reference to learn more about the details of a specific topic. This article rather focuses on overviews, best practices and tips about Git which are not necessarily the top links for a search on Git documentation.
Let us begin with some introductory material.
- Try Git
- Aha! Moments When Learning Git
- Git in Two Minutes for a Solo Developer
- Learn Git Branching
- Git Immersion
The following are more complete Git overviews.
These links are about solving or understanding specific yet typical Git use cases.
- Flow Chart for Solving Typical Git Use Cases
- Curated Git Links of 2014
- Git Merge vs. Rebase
- How to Rebase a Pull Request
- Most Common Git Screwups/Questions and Solutions
- How to Undo Almost Anything With Git
- On Undoing, Fixing or Removing Commits in Git
As Git is very powerful but also flexible there is a need to understand the various possible workflows achievable with this tool.
In my opinion, one should try to keep the amount of long lived branches
to a minimum and, in general,
follow my last name.
I personally like to keep the default
master as the canonical branch
to have the latest integrations or changes but still be deployable.
At the end of the day, the best Git workflow really depends on the type of
project and there is no absolute best. Nonetheless, the following
is my personal favorite when applicable.
To deeply understand Git and come up with solutions (from first principles) for a unique problem on has it can be very helpful to understand Git’s inner workings.
This one’s especially great but I think you’ll only appreciate it after having worked with git for some time. ↩
There are many other valid branch naming schemes, of course, and at the end of the day these names are nothing but smoke and mirrors. You probably still need to know the specific, employed workflow of a project to make sense of the branches. ↩
The resource is so good it’s listed twice :). ↩