this post was submitted on 06 Mar 2024
30 points (91.7% liked)

Git

2882 readers
2 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
 

Story time...

all 27 comments
sorted by: hot top controversial new old
[–] robinm@programming.dev 11 points 8 months ago (1 children)
[–] canpolat@programming.dev 2 points 8 months ago (1 children)

I don't think I read that one. I created a separate link-post for that one. Thanks.

[–] robinm@programming.dev 3 points 8 months ago

I reread that article every years for a few years. Each time my understanding of git improved significantly.

[–] mundane@feddit.nu 10 points 8 months ago

When a colleague generated a dia graph for each git object that got created when he made a few commits. Understanding the underlying data model was a real aha moment. 13 years later and I'm still grateful for his "mini git course".

[–] xilliah@beehaw.org 8 points 8 months ago

I think it might be coming any year now!

[–] morphballganon@lemmy.world 7 points 8 months ago (1 children)

Why not share your own to get the ball rolling?

[–] canpolat@programming.dev 6 points 8 months ago (1 children)

Mine happened when I watched Paolo Perrota's Git courses on Pluralsight. That's when it clicked for me.

[–] whynotzoidberg@lemmy.world 1 points 8 months ago (1 children)
[–] canpolat@programming.dev 3 points 8 months ago

What checkout actually does. Here is a past comment with links to the courses (they are pay-walled, unfortunately)

[–] nothead@lemmy.world 7 points 8 months ago

That time I accidentally wiped an entire open source project on github and had to learn real quick how to undo a destructive commit.

Somehow after an entire night of google-fu, reading the git book three times, and tutorial videos, I got the right series of commands to fix it and nobody ever figured out what I did.

All I wanted to do was fix a typo in an imported module...

[–] technom@programming.dev 6 points 8 months ago* (last edited 8 months ago)

You never reach a phase when you can confidently say that you understand git. But it's certainly possible to go from "When something goes wrong, I just delete the repo and clone it again" to "Aha! Now I can deal with most of the issues".

Mine was when I realized that git commands come in two flavors. Those that deal with commits as snapshots (commit, checkout, switch, reset, etc) and those that deal with commits as changes/diffs/deltas (merge, rebase, cherrypick, revert, etc). (Note: This isn't about how git stores commits on disk). I believe that this is actually the main source of confusion for beginner and intermediate git users.

[–] cafuneandchill@lemmy.world 5 points 8 months ago

When I first saw this post, it had no comments on it, and thought to myself "Wouldn't it be kinda funny if nobody answers that question?"

Don't think I ever had any particular epiphanies concerning Git? Maybe when I played Oh My Git?

[–] Croquette@sh.itjust.works 5 points 8 months ago

When I took time to learn the CLI so I don't need to use any GUI. Still an amateur, but at least git isn't a black box anymore.

[–] magic_lobster_party@kbin.run 4 points 8 months ago (1 children)

When I learned about the reflog. I became less afraid of my changes when I knew I could easily recover from my errors. This allowed me to experiment more with git and become more proficient in it.

Another aha moment was learning that an easy way to squash commits is just to do a git reset followed by git commit -am “whatever”

[–] technom@programming.dev 2 points 8 months ago

Another aha moment was learning that an easy way to squash commits is just to do a git reset followed by git commit -am “whatever”

You can do that in a single step instead with git commit -a --amend.

[–] ikidd@lemmy.world 3 points 8 months ago

Probably about 3 years from now.

[–] BestBouclettes@jlai.lu 3 points 8 months ago

I feel like I'm yet to have my ahah.

[–] ExperimentalGuy@programming.dev 3 points 8 months ago

I initially just used it on personal projects just so I could rollback if I needed to. Afterwards I realized that you could branch after watching Fireship videos. I never got an aha moment, but the moment I really understood was after my first pull request to a project I liked at the time.

[–] corsicanguppy@lemmy.ca 3 points 8 months ago

It's only been a decade. Hasn't happened yet.

sccs, clearcase, rcs, cvs, sure. I'm still deeply in dunning-kruger land for git.

[–] NigelFrobisher@aussie.zone 2 points 8 months ago (1 children)

When I learned that Linus was behind it, otherwise something more straightforward would likely have won the most mindshare.

[–] technom@programming.dev 2 points 8 months ago

That blame must go to github. Not Torvalds.

[–] Kissaki@programming.dev 2 points 8 months ago

I don't think I had a moment like that.

I discovered it, along with other DVCS when it came up, and looked into it and learned it. It was reasonable and intuitive enough for me. As far as I can remember anyway. (I don't have particular memories of that.)

[–] brb@sh.itjust.works 1 points 8 months ago

I just use github desktop. Why bother with anything else?

[–] Buttons@programming.dev 1 points 8 months ago* (last edited 8 months ago) (1 children)

Every commit lists one or more parents, possibly several parents, like 8 parents. These commits thus form a graph structure.

Branches and labels are just references to commits in this graph structure; they are commit alias, just a name that references a specific commit. Branches and tags are the same, except by convention the CLI will move branches when you commit to a branch, but tags are not moved by the CLI.

(Commits may have many names, they have their commit ID, and they may also be named by a branch or tag. Commit IDs are hashes of the contents of the commit. This ensures, cryptographically, that a commit and it's ID can never change.)

Git never deletes a commit that is less than 90 days old. If you commit something, rest assured your work is in there somewhere, it's just that no mortal being may be able to find it. Deleting a branch removes a reference to a commit, but the commits in the branch are still there. The GUI tools usually hide commits that are not part of a branch, but you can see them using "reflog" related commands.

[–] technom@programming.dev 3 points 8 months ago

possibly several parents, like 8 parents

Fun fact. Such merges with more than 2 parents are called 'octopus merges'. The Linux repo has a single merge with 66 parents that Torvalds named the 'Cthulhu merge'.

Git never deletes a commit that is less than 90 days old.

On its own, that is. Not if you do a git gc.

Deleting a branch removes a reference to a commit, but the commits in the branch are still there.

but you can see them using “reflog” related commands

Reflog - one of the most underrated git commands that has the potential to save your life some day. At least one team member must learn it.

[–] onlinepersona@programming.dev 0 points 8 months ago

Still haven't. And I really dislike articles that say stuff like "git doesn't really store diffs!" followed by a bunch of paragraphs showing they don't understand what git does store or they are bad at explaining things (or both).

Great. Wow, that explains everything.

Or stuff like "git branches aren't really branches!" 😑

CC BY-NC-SA 4.0