this post was submitted on 07 Sep 2024
109 points (99.1% liked)
Programming
17511 readers
80 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So the big important part of git is that it's a collection of commits. A branch is just a labeled commit and each commit is a list of what changed from the parent. Rebasing (the most confusing one for people) is when you fiddle with a commit from underneath yourself. Or in even more simple terms editing a parent commit. Rebasing is extremely powerful but most useful for when you notice a bug you wrote a couple commits ago. Fixing such issues via rebase (or
!fixup
commits you auto squash at the end) keeps your history clean. It's as though you never wrote the bug. The other thing you do a lot with rebasing is moving your branch up in the history cause somebody updated the remote.I mean, this could be useful, but I need a much higher level of understanding. When I was a dev, all we used was basically version control. There was no concept of commit, pulls, etc. I'm having to understand this from a standpoint of no understanding whatsoever. For most devs, they've done this for at least a decade with Git. Git is so much more complicated than a simple version control. I understand why it's necessary for large teams, but I still see it lke this:
You likely have a mental model of Subversion, so what I would suggest is to try to forget as much of it as possible first, as Git is very different.
Take a tutorial that is aimed at Git beginners, e.g. [1]. This will help you start building a new mental model as well as get first practical experience.
After that, read the official docs starting wtih the object model[2]. The reason why many people struggle to get into git, especially after using other VCS, is that it was built from the ground up, without much regard of the established conventions and terminology. Linus Torvalds once mentioned that he used his experience designing file systems when developing git.
So the object model of git is very simple, but also not intuitive. However, once you understand it, everything will start making sense, including the xkcd you've linked.
[1] https://gitimmersion.com/ [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
You've linked into it, but I was just going to point at the Git book: https://git-scm.com/book/en/v2
It's an afternoon's reading; it does an excellent job of giving you the right mental model - and a crib aheet of commands to navigate it.