Yeah learned this the hard way.

  • marcos@lemmy.world
    1·
    2 months ago

    You know… A version control system… That class of software that makes it possible for you to recover from any error you commit.

  • QuizzaciousOtter@lemmy.dbzer0.com
    1·
    2 months ago
    1. Use git for any code you write. Yes, even a simple script.
    2. Commit and push often. More often than you think is reasonable. You can always rebase / fixup / squash / edit but you can’t recover what you didn’t commit.
    3. ???
    4. Profit.

    Seriously, once you commited something to the repo it’s hard to lose it. Unless you delete .git. But a this point frequent pushing has your back.

    I know git can be hard to grasp in the beginning. It was hard for me too. I highly encourage everyone to put in the effort to understand it. But if you don’t want to do that right now just use it. Just commit and push. It will pay off.

  • kibiz0r@midwest.socialEnglish
    0·
    2 months ago

    Git repository operations are (almost?) always recoverable. git reflog is your friend.

    The filesystem operations are another story. Handle with care.

      • kibiz0r@midwest.socialEnglish
        0·
        2 months ago

        Think of it like your browser history but for Git. It’s a list of the SHAs related to your recent operations.

        And because Git is a content-addressable data store, a SHA is basically like a URL. Even if a branch no longer exists, if you know the SHA it pointed to then you can still check out the exact contents of that branch. The reflog helps you find that.

  • Ephera@lemmy.mlEnglish
    0·
    2 months ago

    I’ve had juniors who didn’t believe this, so just to say it: If you know what you’re doing, practically any Git problem is recoverable.

    The one major exception is if you delete your local changes before committing them.

    • sorter_plainview@lemmy.today
      0·
      2 months ago

      Yeah.But many of them are extremely annoying. Specifically screwing up rebase. It is recoverable, but very annoying.

      That said I have seen juniors make two other common mistakes.

      1. Pushing your commit without fetching
      2. Continuing on a branch even after it was merged.

      I’m fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.

      • psycotica0@lemmy.ca
        0·
        2 months ago

        Maybe I’m just a wizard, or I don’t know what y’all are talking about, but rebases aren’t special. If you use git reflog it just tells you where you used to be before the rebase. You don’t have to fix anything, git is append only. See where the rebase started in reflog, it’ll say rebase in the log line, then git reset --hard THAT_HASH

        Pushing without fetching should be an error. So either they got the error, didn’t think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.

        Continuing after merge should be pretty easy? I’d assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly git rebase -i and then delete lines look like they were already merged?

        • sorter_plainview@lemmy.today
          0·
          2 months ago

          See all this is fine for someone with good experience in git. They know how to solve the screw up. But wih junior devs, who don’t know much about it, they will just get confused and stuck. And one of the senior has to involve and help them solve. This is just annoying because these can be avoided very easily. Until they understand the pattern of how everyone operates with git, it just creates issues.

          To me first time causing this issue is completely fine. I will personally sit with them and explain then what went wrong and how to recover. Most of them will repeat it again, act clueless and talk like they are seeing this for the first time in their life. That is the difficult part to me.

          May be I’m just old school, and a grumpy old person, even though I’m not that aged.

          • zalgotext@sh.itjust.works
            1·
            2 months ago

            Sounds like the onboarding process needs to have a step in it that says “here’s a link to a git tutorial, read this and get familiar with using git, as it’s an integral tool that you will use every single day on the job”. Bonus points for providing a sample repo that juniors can use to mess around with git, extra bonus points for including steps in the onboarding materials for the juniors to set up their own repos to play around with.