Git is one of those things that take a bunch of learning to understand but is makes perfect sense once you do. I read like half of the pro git book and after that I was like it’s so simple! If course it still requires you to read half a book…
For some reason I’ve always been able to visualize version control systems and workflows pretty well and understand how they work. I used to host a CVS server when I was in college back in 2001 so my teammates and I we could collaborate on our lab projects. Then moved on to Subversion, which I used for a very long time. Then I worked at a small company who used Canonical’s Bazaar and finally joined a big corp who used Git.
Throughout the years I simply developed some good practices that I applied to Git and that seemed to be enough. But, I’d occasionally get into this detached head state that I didn’t really understand. And this happened often with my teammates at that job. They’d end up with bizarre scenarios. So I started reading the book and experimenting and was soon pretty solid in Git and ended up being the SME on that topic for our team. Everyone would come to me when they got stuck.
I’m still learning new shit about Git even 8 years later lol. But, the step from being a newbie to a normal user is really big.
Cloning a repo to build the source code isn’t even remotely hard.
When you manage the repo of an entire team who work together on different release versions of a product using a very specific workflow with squash commits and cherry-picking? And when team members fuck up the repo’s history with a bad git pull/push? Yeah, it gets more complicated.
Even with merge policies, if someone doesn’t understand what they’re doing or how it works, it won’t help.
Last project I worked on, we asked our developers to rebase on the parent branch and squash on their pull requests. But, they often encountered conflicts because they never updated their branch. They would pull the parent branch into their feature breach, or do a regular merge, or merge different other branches together and you’d end up with commit duplication everywhere. They didn’t have any discipline.
I refuse to believe that anyone other than Linus knows how to use git.
Git is one of those things that take a bunch of learning to understand but is makes perfect sense once you do. I read like half of the pro git book and after that I was like it’s so simple! If course it still requires you to read half a book…
Yes! And the book is free. You can download it in PDF if you want.
For some reason I’ve always been able to visualize version control systems and workflows pretty well and understand how they work. I used to host a CVS server when I was in college back in 2001 so my teammates and I we could collaborate on our lab projects. Then moved on to Subversion, which I used for a very long time. Then I worked at a small company who used Canonical’s Bazaar and finally joined a big corp who used Git.
Throughout the years I simply developed some good practices that I applied to Git and that seemed to be enough. But, I’d occasionally get into this detached head state that I didn’t really understand. And this happened often with my teammates at that job. They’d end up with bizarre scenarios. So I started reading the book and experimenting and was soon pretty solid in Git and ended up being the SME on that topic for our team. Everyone would come to me when they got stuck.
I’m still learning new shit about Git even 8 years later lol. But, the step from being a newbie to a normal user is really big.
Yeah back before github existed, we used sourceforge to host opensource, and you had to use CVS. Then later Subversion.
I know how to use git. It’s not that hard.
Hi Linus!
Oh boy are you in for a shock to know that I use git all the time when I want a piece of software that isn’t available in YaST2, Flatpaks or Appimages
I mean understand and know when or how to use every feature and command, I don’t mean using
git clone https://github.com/foo/baroccasionally.Cloning a repo to build the source code isn’t even remotely hard.
When you manage the repo of an entire team who work together on different release versions of a product using a very specific workflow with squash commits and cherry-picking? And when team members fuck up the repo’s history with a bad git pull/push? Yeah, it gets more complicated.
If a team member can fuck up the history you probably should look into your merge policies.
Even with merge policies, if someone doesn’t understand what they’re doing or how it works, it won’t help.
Last project I worked on, we asked our developers to rebase on the parent branch and squash on their pull requests. But, they often encountered conflicts because they never updated their branch. They would pull the parent branch into their feature breach, or do a regular merge, or merge different other branches together and you’d end up with commit duplication everywhere. They didn’t have any discipline.