• @lily33@lemm.ee
    26•1 year ago

    Learning git is very easy. For example, to do it on Debain, one simply needs to run, sudo apt install lazygit

    • @jcg@halubilo.social
      1•1 year ago

      I’d still probably prefer the usual CLI for setup, commits, pushes etc. but this looks like a godsend for any branching/rebasing operations!

      • @lily33@lemm.ee
        1•1 year ago

        The ease with which I can only commit separate hunks with lazygit has ensured I use it for commits, too. And once I’ve opened it to do the commit, I may as well also press P.

        • Alex
          1•1 year ago

          Is this what people who haven’t been introduced to #magit use?

          • @lily33@lemm.ee
            1•1 year ago

            Never tried magit, but it doesn’t matter. It couldn’t possibly be good enough to be worth using an inferior editor.

    • Kata1yst
      25•1 year ago

      LazyGit may actually be black magic from Satan to tempt programmers into sin. And to that I say: ‘where is a goat I can sacrifice to my dark lord?’

    • Bipta
      3•1 year ago

      Wow this looks great. Amend an old commit dealing with a rebase? Sign me up!

      • @zalgotext@sh.itjust.works
        5•1 year ago

        git rebase -i origin/main (or whatever branch you’re rebasing on), then read the instructions that come up in the editor window

        • corytheboyd
          10•1 year ago

          Read… instructions? I love teaching people that git very often prints out what you should do next.

          git: “to continue, resolve conflicts, add files, and run rebase —continue”
          dev: …time to search stack overflow

          All that said… just use lazygit. It does help to know CLI git first to put things in context, but if you do, no need to punish yourself every day by not using a UI.

  • @erogenouswarzone@lemmy.mlEnglish
    12•1 year ago

    Great meme, and I’m sure op knows this, but for anyone else who is curious…

    007 in theory means:

    • 00: you have already committed your code to your local code base
    • 7: When you try to merge your code with everyone else’s there are 7 files that others have worked on since you last refreshed your local code base.

    To resolve this, you need to go file by file and compare your changes with the changes on the remote code. You need to keep the changes others have made and incorporate your own.

    You can use git diff file_name to see the differences.

    If you have made small changes, it’s easier to pull and force an overwrite of your local code and make changes again.

    However multiple people working on the same files is usually a sign of organizational issues with management. Ie, typically you don’t want multiple people working on the same files at the same time, to avoid stuff like this.

    If you’re not sure, ask someone that knows what they’re doing before you follow any advice on Lemmy.

      • @zalgotext@sh.itjust.works
        1•1 year ago

        If you use a squash workflow, you’re going to be force pushing a ton.

        Never force git to do anything. If you’re forcing something you’re doing it wrong.

        This is bad advice. Better advice would be “know and understand your tool, and know the consequences of your actions”.

      • @jjjalljs@ttrpg.network
        4•1 year ago

        If I get a big conflict and I know my change is trivial, I feel perfectly okay doing git fetch git reset --hard whatever and then reapplying my simple change as a new commit. Sort of a bootleg rebate.

      • @erogenouswarzone@lemmy.mlEnglish
        2•1 year ago

        I hear what you’re saying.

        First, I hard disagree with you. Overwriting my local version of code is a parachute - not an ideal landing, but better than merging by hand.

        Also, my comment was not an attempt to teach everything about git, just to explain what is happening in simple terms, since git requires a lot of experience to understand what those messages mean.

  • Haus
    6•1 year ago

    sccs, rcs, cvs… after that it’s a blur of new systems every year or two

  • @dan@upvote.au
    3•1 year ago

    Honestly, just use a GUI. Graphical user interfaces were designed for a reason. I usually use SourceTree or the Git functionality built in to Visual Studio or VS Code.

    It’s good to know how things work under-the-hood (e.g understand Git’s object model, some basic commands, etc) but don’t feel like you need to use the command-line for everything.

    • kamen
      1•1 year ago

      My take is use a GUI for anything read-only/nondestructive (i.e. anything that won’t modify your local or remote state). It’s nice for example to compare the state of two branches.

      For anything that does changes make sure you know what’s happening under the hood, otherwise you might shoot yourself in the foot. It’s convenient for example to do a commit and push in one go, but then you lose the ability to edit any changes (you’re forced to either do another commit, or change your local commit and force push).

      In VSCode you can go to the Output pane and switch to Git - there you’ll see everything that gets done through Git’s CLI for whatever you do through the GUI (although it can be a bit noisy); same goes other GUI utils.

    • @zalgotext@sh.itjust.works
      14•1 year ago

      In my experience, using GUIs is how people fuck themselves, and then I have to unfuck them via the command line.

      Git’s interface is bad, yes. It has a step learning curve, yes. But I truly think the only real way to overcome those obstacles is to learn how git works, learn all the nitty gritty details, not hide from them.

      • @CapeWearingAeroplane@sopuli.xyz
        5•1 year ago

        I use a GUI (GitKraken) to easily visualise the different branches I’m working on, the state of my local vs. the remote etc. I sometimes use the gui to resolve merge conflicts. 99 % of my gut usage is command line based.

        GUI’s definitely have a space, but that space is specifically doing the thing the command line is bad at: Visualising stuff.

    • @lseif@sopuli.xyz
      1•1 year ago

      lazygit or tig are terminal interfaces for git. very nice, best of both worlds imo. every action shows the git command ran at the bottom, and its a lot easier to see at a glance the status, diff, log, etc.

    • fox [comrade/them]English
      1•1 year ago

      It’s definitely not simple to use but I agree that the conceptual model it represents is straightforward. I think a lot of the problems people have with git come from not understanding the underlying data structure before learning how to manipulate it.

    • Shinji_Ikari [he/him]English
      1•1 year ago

      Its not dead simple but its also not extremely complex.

      I’m currently working with some interns and there’s just concepts they were never exposed to. Without decent mentoring, git can be difficult because a lot of the workflow does come with experience.

      That being said everyone needs to stop acting like its an impossible task to properly do source control. There is some truth that if you don’t care enough to do your source control, you don’t care enough to write decent code. Its not a moral failing, just take some pride in your craft.

      Show the newbies how to care and they’ll care enough to want to do it right. Measure twice, cut once and all that.

    • oce 🐆
      13•1 year ago

      If it was dead simple you wouldn’t need to learn 10 new concepts and google commands regularly even after using it for a couple of years. You probably forgot how you struggled at first. I have taught it multiple times and I see how beginners struggle.

    • space_comrade [he/him]English
      13•1 year ago

      It’s not THAT complicated but I wouldn’t call it dead simple. When you understand how git works internally yeah it’s pretty simple but people usually start with the idea that it’s a tool to put your code on a server to synchronize with other people and only later learn that you have both a local and a remote (or multiple remote) tree and how the tree really works.

      I think the problem is most git 101 tutorials teach it wrong, IMO the best git tutorial is this: https://wildlyinaccurate.com/a-hackers-guide-to-git/

      Unfortunately it’s pretty dense so it’s gonna scare off a lot of newbies.

      • @buzziebee@lemmy.world
        2•1 year ago

        It’s doable once you know what you’re doing. I can do it all via the cli, but I personally use gitkraken most of the time and it’s just so much easier and more ergonomic.

        I also see a lot of the Devs who insist they know what they’re doing create horrible messes of their branches super easily via the commit tree. People should just use whatever works best for them to get the job done.

      • @lightnegative@lemmy.world
        13•1 year ago

        Do it enough times and it stops being scary.

        Using a tool like VSCode to perform the actual merges on individual files also helps because it shows what “yours” and “theirs” changes are from a user perspective, not a git perspective

        • @boomzilla@programming.dev
          2•1 year ago

          The 3-way merge editor in VSCode is a fantastic tool. Really helps in visualizing what comes from where and preventing merge accidents.

    • @sajran@lemmy.mlEnglish
      5•1 year ago

      I would actually say it’s VERY complicated but in daily work you probably need like 5 commands and those aren’t hard at all.

  • @lseif@sopuli.xyz
    70•1 year ago

    if u ever get a tricky merge conflict, just git push --force. this automatically works out the right code to keep (your own)

  • katy ✨
    36•1 year ago

    lemme rebase the main branch onto my branch.

    two minutes later

    1 merge conflict of 57 [abort] [continue]

    • kamen
      7•1 year ago

      One key thing that can help you wrap your head around rebasing is that branches get switched while you’re doing it; so, say you’re on branch feature and do git rebase master, for any merge conflict, whatever’s marked “current” will be on master and what’s “incoming” is from feature.

      There’s also git rerere that should in theory remember a resolution you do between two branches and reuse it every time after the first; I’ve rarely used it in practice; it would happen for long lived branches that don’t get merged.