Programming

17444 readers

184 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

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

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

105

I need help getting back into development (lemmy.sdf.org)

submitted 2 months ago by jawa21@lemmy.sdf.org to c/programming@programming.dev

52 comments fedilink hide all child comments

A little background: Through my teens in the 90's I did a lot of the things you may expect. I was a script kiddie on mIRC, made a tank game in Unreal Engine, and did some Quake modding. From 2002-2004 I landed a job doing Java web dev, SQL, and overall database administration because my father's friend needed someone that could do that. I was ok at the job, but not great. Being young, my hobby that turned into a 9-5 made me want to stab my eyes out and I quit.

With that said, I can understand a lot of what's going on, but it doesn't "click" anymore. I spent 20 years as a career machinist, but I physically can't do that anymore. Here's the rub - my twin brother is a brittle diabetic and can't work (lots of other stuff going on as well), and our mother is getting old (father passed this year). The only reasonable way forward that I can see in order to be able to support my brother is trying to get back into development.

When I stopped, subversion was what we used. I'm trying to understand Git, but it's a giant conceptual leap. I guess, what I'd like to hear from you all is a way to jump back in as quickly as possible in such a way that it may be a career.

Thanks

you are viewing a single comment's thread
view the rest of the comments

[–] Traister101@lemmy.today 3 points 2 months ago* (last edited 2 months ago) (3 children)

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.

[–] jawa21@lemmy.sdf.org 2 points 2 months ago (2 children)

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:

[–] hades@lemm.ee 4 points 2 months ago (1 children)

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

[–] gedhrel@lemmy.world 2 points 2 months ago

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.