Recently I presented Git to my colleagues in one of our dev meetings. Prior to that I did some research on the topic, looking through some of my git related bookmarks and on the internet. It resulted the following list of articles I wish I read when I started with git:
I recommend you read the articles in the order listed here
Especially useful for newcomers, and in particular those who have come from using CVS or Subversion. But also if you are already a git user you may find it refreshing.
In his pursuit to understand Git, it’s been helpful for the author to understand it from the bottom up – rather than look at it only in terms of its high-level commands. And since Git is so beautifully simple when viewed this way, he thought others might be interested to read what he has found.
This is currently the most rated git article on dev.to and for good reason. It is an interactive git tutorial with hand drawings meant to teach you how git works, not just which commands to execute.
This website is designed to help you understand some basic git concepts visually.
Adding/staging your files for commit will not be covered by this site. In all sandbox playgrounds on this site, just pretend that you always have files staged and ready to commit at all times.
While making a point about why you should use fetch and merge instead of pull, the author introduces you to branch management.
git rebase with the related
git merge command and identify all of the potential opportunities to incorporate rebasing into the typical Git workflow
The sooner you get to know
git rebasethe cleaner your git log history will look ;)
The article tries to answer the question - "In a software team using git and feature branching, what's the best way to incorporate finished work back to your main line of development?" Pros and cons of both approaches are presented and also addresses the rebase as local cleanup, which is a different thing than rebase as team policy.
It is not until recently that I got to use this command, which helps you reduce the time to find your "faulty" commit exponentially - very useful and easy to use as presented in this article.
This article I did actually read in my first days of Git and even this workflow for a long time in different companies and even in the early stage of Bookmarks.dev development - I leave it here as it shows the easiness of using Git as a version control system where branches are very cheap to manage. Nowadays we mostly use the Github flow which the article also mentions.
Most of articles mentioned here are also find publicly listed and tagged