• seth@lemmy.world
      link
      fedilink
      arrow-up
      171
      arrow-down
      4
      ·
      edit-2
      5 months ago

      It’s git push origin branch and then merge after submitting a pull request from branch to main after a successful lint check, build, deployment, and testing in a non-production environment, and PR approval. What kind of wild west operation allows pushing directly to main?

      • redcalcium@lemmy.institute
        link
        fedilink
        arrow-up
        39
        ·
        5 months ago

        Employees who push first win and get to leave early. The rest would be the suckers who would merge whatever mess left behind by the early employees.

        • Pacmanlives@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          5 months ago

          Hey there were like 3 of us lol! No joke that’s what I have done at a few of the smaller shops as an SRE/System Engineer

      • dan@upvote.au
        link
        fedilink
        arrow-up
        10
        ·
        edit-2
        5 months ago

        Our changes land in main at my workplace, once they’ve received a code review and all CI checks pass (which includes tests, E2E tests, etc). We use feature flags rather than feature branches, so all diffs / pull requests are against main. We use continuous deployment which means changes are automatically deployed once landed. Changes roll out just to employees, then to servers used by a small percentage of users (2% I think), then everywhere. All risky changes are gated by feature flags so they can be enabled or disabled without a code push.

        • nilloc
          link
          fedilink
          English
          arrow-up
          3
          ·
          5 months ago

          We did a similar way with tag based releases, first a test tag, the production tag when signed off.

      • MR_GABARISE@lemmy.world
        link
        fedilink
        arrow-up
        10
        arrow-down
        1
        ·
        5 months ago

        What kind of wild west operation allows pushing directly to main?

        That’s kinda the whole point of trunk-based development.

      • AA5B@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        5 months ago

        No kidding. Never push to main, and you most likely can’t. While I get the joke of the meme, I’d send the person packing if they don’t understand branching, and branch flow, rebasing or reverting. Even if you look up the command or do it all through your IDE, understanding the workflow of using git is important

      • SpaceCowboy@lemmy.ca
        link
        fedilink
        arrow-up
        4
        ·
        5 months ago

        They laid off everyone else so there’s no one to the code reviews now. So fuck it, we’ll do it live!

        • AA5B@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          5 months ago

          We just had a customer escalation caused by exactly this. One group relied too heavily on tribal knowledge for code reviews and didn’t want any other process. Once the tribal elders were gone, no one knew all the things to look for, and there was no other way to catch issues

          As a Continuous Integration and Test guy, I was standing in the corner yelling “I thought you were DevOps. Where’s the automation?” Fine, Puppet/YAML doesn’t work with a traditional build and test, but you could have done syntax validation and schema validation that would have caught before the code review could have happened (and I showed them how a year ago, even offered to do it for them) and set up some monitoring to discover when you break stuff, before customers discover it.

      • 1984@lemmy.today
        link
        fedilink
        arrow-up
        2
        ·
        5 months ago

        I never worked anywhere where they had this set up. I would push to branches and make pull requests, but always work in the production environment.

        I was mainly working as a data engineer though so that’s probably why. It’s hard to have test environments since you can’t replicate all the enormous amounts of data between environments without huge costs.

        • expr@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          5 months ago

          There are many strategies for maintaining test environments for that kind of thing. Read-only replicas, sampling datasets for smaller replicas, etc. Plenty of organizations do it, so it’s not really an excuse, imo.

          • 1984@lemmy.today
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            5 months ago

            No I know. But it was “good enough” for the company and we never had any serious issues working that way either. If someone pushed a faulty commit, we just reverted it and reloaded the data from the source system.

            A lot of companies have kind of bad solutions for this sort of stuff, but it’s not talked about and nobody is proud of it. But it keeps the environments simple to work with.

      • korok@possumpat.io
        link
        fedilink
        arrow-up
        2
        ·
        5 months ago

        Do you not use a fork as your origin, separate from the production upstream repo? I’ll push to my fork’s main branch for small or urgent changes that will definitely be merged before anything else I’m working on.

        • Solemn@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          5 months ago

          If it’s a private repo I don’t worry too much about forking. Ideally branches should be getting cleaned up as they get merged anyway. I don’t see a great advantage in every developer having a fork rather than just having feature/bug branches that PR for merging to main, and honestly it makes it a bit painful to cherry-pick patches from other dev branches.

        • Nalivai
          link
          fedilink
          arrow-up
          1
          ·
          5 months ago

          You mean “I just sent you zip file with my new changes via email, get fucked looser”?

      • OpenStars@startrek.website
        link
        fedilink
        English
        arrow-up
        26
        arrow-down
        1
        ·
        5 months ago

        I have only ever used simply “git push”. I feel like this is a “how to say that you barely know how to use git without saying that you barely know how to use git” moment:-D.

        • synae[he/him]@lemmy.sdf.org
          link
          fedilink
          English
          arrow-up
          9
          ·
          5 months ago

          Normal distribution curve meme makes sense here - experts and noobs can both git push safely (but for different reasons)

          • OpenStars@startrek.website
            link
            fedilink
            English
            arrow-up
            6
            arrow-down
            2
            ·
            5 months ago

            I can follow along re-typing the same commands told to me by a more senior dev just like any average monkey!

            This reminds me of something I made a long time ago: img

            Since I am calling myself dumb, I estimate my progress to be somewhere perhaps at the 20th percentile marker? :-D One of these days I’ll RTFM and rocket all the way up to be dumb enough to properly qualify for “below average”! :-P

          • body_by_make@lemmy.dbzer0.com
            link
            fedilink
            arrow-up
            23
            ·
            edit-2
            5 months ago

            You can default git to using your current branch and a specific upstream so you don’t have to put anything after git push

              • bleistift2@feddit.de
                link
                fedilink
                English
                arrow-up
                7
                arrow-down
                1
                ·
                5 months ago

                Has git never told you that you should use git push -u origin <branch> when you push a new branch for the first time?

          • PoolloverNathan@programming.dev
            link
            fedilink
            arrow-up
            16
            ·
            5 months ago

            The first time you manually push like that, you can add the -u flag (git push -u origin master) to push and set the branch’s default upstream. Afterwards, a plain git push while that branch is checked out will push the branch to that default upstream. This is per-branch, so you can have a main branch that pulls from one repository and a patch branch that pulls and pushes to a different repository.

            • blind3rdeye@lemm.ee
              link
              fedilink
              arrow-up
              6
              ·
              5 months ago

              My strategy is to just type git push and get some kind of error message about upstream not being set or something. That’s a signal for me to take a second to think about what I’m actually doing and type the correct command.

              • embed_me@programming.dev
                link
                fedilink
                arrow-up
                1
                ·
                5 months ago

                That’s a signal for me to

                … google the error and randomly try stack overflow answers without really understanding them.

                ( I have changed)

    • RustyNova@lemmy.world
      link
      fedilink
      arrow-up
      24
      arrow-down
      18
      ·
      5 months ago

      Fuck those that use main. If you’re working on a library fork that has main and a project that has master you’re bound to invert the two.

      “What do you mean I can’t checkout main? Oh right, here it’s master…”

      For once that we had a standard, it had to be ruined.

      • huginn@feddit.it
        link
        fedilink
        arrow-up
        37
        arrow-down
        17
        ·
        5 months ago

        Fuck those that use master. If you’re working on a library fork that has main and a project that has master you’re bound to invert the two.

        “What do you mean I can’t checkout main? Oh right, here it’s master…”

        For once that we had a standard, it had to be ruined.

        The standard is now main.

        • maynarkh@feddit.nl
          link
          fedilink
          arrow-up
          23
          arrow-down
          3
          ·
          5 months ago

          The standard is now main.

          Git itself does not use that standard yet, so at least now there are two competing standards.

          I get that there are cultural reasons why the word master was loaded language, but still, it’s not like institutional racism will go away. Meanwhile, the rest of the world which doesn’t struggle with the remnants of slavery has to put up with US weirdness.

          • zalgotext@sh.itjust.works
            link
            fedilink
            arrow-up
            14
            arrow-down
            1
            ·
            5 months ago

            Git itself does not use that standard yet, so at least now there are two competing standards.

            Just ran git init in a brand new empty directory, and while it did create a master branch by default, it also printed out a very descriptive message explaining how you can change that branch name, how you can configure git to use something else by default, and other standards that are commonly used.

            Also, there’s nothing saying your local branch name has to match the upstream. That’s the beauty of git - you have the freedom to set it up pretty much however you want locally.

            • maynarkh@feddit.nl
              link
              fedilink
              arrow-up
              7
              arrow-down
              1
              ·
              5 months ago

              Yeah, that’s what I’m saying, there is no one standard now. The stupid thing is all the problems that causes is mostly because there used to be one, and stuff written assuming master branches are eternal.

              I’ve had a company that had some automation built on git but below GitLab that would not let you delete master branches. When main became a thing, they just started hard protecting those as well by name. It’s because of regulatory, and they are very stingy about it.

              So when I created a few dozen empty deployment repos with main as the default, and then had to change it over to master so that it lined up nicer with the rest of the stuff, I’ve had a few dozen orphaned undeletable empty main branches laying around. A bit frustrating.

              That said, the whole thing is just that. A bit frustrating. If it makes some people feel better about themselves, so be it. I am blessed in life enough to take “a bit frustrating”.

              • zalgotext@sh.itjust.works
                link
                fedilink
                arrow-up
                3
                ·
                5 months ago

                Yeah that’s fair, I can see how that would be annoying for sure. I think that frustration stems more from company policy though, not necessarily the standard changing. And you know what they say, there’s nothing certain in this world except for death, taxes, and standards changing

                • maynarkh@feddit.nl
                  link
                  fedilink
                  arrow-up
                  4
                  ·
                  5 months ago

                  It is trash code for sure, but most of the world’s code is trash, so we do have to accommodate trash code when we design stuff. That said, they do need to do this to comply with laws and make sure code doesn’t get lost (it’s finance), and this was the easy way to do it. Doing it better would have taken time and attention away from other stuff.

                  And standards do change, but they usually change to accommodate new features, or a new software product displaces an old one. I don’t really know any tech standard that changed because of cultural reasons. Point is, change is a cost. It may be worth to pay the cost, but here the benefits were US cultural sentiments that most of the world doesn’t care about.

                  And the stupid thing is that even when standards change, you are not usually labelled as culturally out of touch if you don’t follow it. Most big orgs don’t follow changes that they don’t need to. Nobody calls you a bigot for running COBOL mainframes in 2023, but they might if you predominantly have master branches.

                  I guess my perspective is that some people I know were mildly annoyed before lunch about it one day two years ago, since nobody cares about US identity politics, with my personal opinion being if the US didn’t fill up its for-profit prisons with black people who it then those prisons profit off of (just as an example), the word master would not bite as hard, and the whole thing would be moot.

      • BatmanAoD@programming.dev
        link
        fedilink
        arrow-up
        8
        ·
        5 months ago

        git checkout ma<tab>

        If you don’t have autocomplete set up for your shell, get it working. If someone has a different branch named ma..., ask if you can delete it, and get your team to adopt a decent branch naming convention.

        • Nalivai
          link
          fedilink
          arrow-up
          3
          ·
          5 months ago
          git checkout ma<tab>
          
          
          mai_new_chenges 
          march_deploy_second_final_final_fixed      
          main_fixes       
          mast_not_farget_to_delete_it
          
          • BatmanAoD@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            5 months ago

            …yeah, I already said that if there is another branch starting with those letters it should be deleted. You need a naming convention.

            • Nalivai
              link
              fedilink
              arrow-up
              2
              ·
              5 months ago

              I really wish to work in a team where people have naming conventions for branches that are concerned about stuff like that. Must’ve been a nice place to work at.

              • BatmanAoD@programming.dev
                link
                fedilink
                arrow-up
                2
                arrow-down
                1
                ·
                5 months ago

                Whoever named the “final final fixed” one seems to have missed the point of version control. 😑

      • 1984@lemmy.today
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        5 months ago

        I think the reasons was ridiculous. The fact that people didn’t like the word master anymore. But I’m used to it now, so fine, let’s use main. It makes sensitive people feel better.

    • dQw4w9WgXcQ@lemm.ee
      link
      fedilink
      arrow-up
      53
      ·
      5 months ago

      I might be the dumb one in this one, but HR asked me if I know “design patterns”.

      “I mean, yes, I know some design patterns. Any specific?”

      “No, just if you are familiar with design patterns.”

      “I mean, there are builder, strategy, sigleton, factory etc. Is the question really not more specific?”

      “My paper just asks if the dev is familiar with design patterns.”

      “Ok. Yes.”

      • Gestrid@lemmy.ca
        link
        fedilink
        English
        arrow-up
        8
        ·
        edit-2
        5 months ago

        Whenever I hear someone say “zed”, it always throws me for a loop. I follow a Canadian streamer, and they use it in place of “zero” the letter “zee”.

        • allywilson@sopuli.xyz
          link
          fedilink
          arrow-up
          5
          ·
          5 months ago

          I’m not Canadian, but as a Brit I also say Zed instead of Zee but I’ve never heard someone say Zed instead of Zero. WTF.

          • Gestrid@lemmy.ca
            link
            fedilink
            English
            arrow-up
            3
            ·
            5 months ago

            Oh, my bad. It was zed instead of the letter “zee”.

            It’s 3am, and I’m exhausted, about to head to bed.

    • KeriKitty (They(/It))@pawb.social
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      5 months ago

      Ahh, that must be where the DEVs use LUA and JAVA and whatever else always irks me. grumps irkily, for emphasis and illustration

  • Punkie@lemmy.world
    link
    fedilink
    arrow-up
    69
    ·
    5 months ago

    The thing is that for a majority of cases, this is all one needs to know about git for their job. Knowing git add, git -m commit “Change text”, git push, git branch, git checkout , is most of what a lone programmer does on their code.

    Where it gets complicated real fast is collaboration on the same branch. Merge conflicts, outdated pulls, “clever shortcuts,” hacks done by programmers who “kindof” know git at an advanced level, those who don’t understand “least surprise,” and those who cut and paste fixes from Stackexchange or ChatGPT. Plus who has admin access to “undo your changes” so all that work you did and pushed is erased and there’s no record of it anymore. And egos of programmers who refuse any changes you make for weird esoteric reasons. I had a programmer lead who rejected any and all code with comments “because I like clean code. If it’s not in the git log, it’s not a comment.” And his git comments were frustratingly vague and brief. “Fixed issue with ssl python libs,” or “Minor bugfixes.”

    • Ottomateeverything@lemmy.world
      link
      fedilink
      arrow-up
      50
      ·
      5 months ago

      I had a programmer lead who rejected any and all code with comments “because I like clean code. If it’s not in the git log, it’s not a comment.”

      Pretty sure I would quit on the spot. Clearly doesn’t understand “clean” code, nor how people are going to interface with code, or git for that matter. Even if you write a book for each commit, that would be so hard to track down relevant info.

      • mkwt@lemmy.world
        link
        fedilink
        arrow-up
        31
        ·
        5 months ago

        Yeah, I think that guy only got a superficial understanding of what Uncle Bob was saying.

        My policy as a tech lead is this: In an ideal world, you don’t need the comment because the names and the flow are good. But when you do need the comments, you usually really need those comments. Anything that’s surprising, unusual, or possibly difficult to understand gets comments. Because sometimes the world is not ideal, and we don’t have the time or energy to fully express our ideas clearly in code.

        My policy on SCM logs is that they should be geared more towards why this commit is going in, not what is being done. And what other tickets, stories, bugs it relates to.

        • PrettyFlyForAFatGuy@lemmy.ml
          link
          fedilink
          arrow-up
          20
          ·
          5 months ago

          Lead of a small team of scripters here. The “Why. Not What” is defo a good way of encouraging cleaner code.

          Had to request changes recently on a PR like this, big function with comments telling me what it was doing. When they resubmitted for review they had broken it down into smaller functions with good variable/function naming. following what was going on was much easier

          • AA5B@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            5 months ago

            Same strategy here, but recently found myself commenting on the “what”. There was a perfect built-in, but not really readable and I couldn’t figure out how to make it readable, so fine

        • bleistift2@feddit.de
          link
          fedilink
          English
          arrow-up
          6
          ·
          5 months ago

          But when you do need the comments, you usually really need those comments.

          It’s nice to see you sharing my experience. My code is either uncommented or very severely commented with comment-to-code ratios of 10:1 or more. I hate the files that are soo green… :(

        • AstridWipenaugh@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          5 months ago

          We solve that problem using naming conventions. Branch names must start with the issue key (we use Jira). You don’t do anything in that branch that’s not part of that issue. If you do, you must prefix the commit message with the issue key that it goes with. The commit itself identifies what changed. The Jira issue provides all the backstory and links to any supporting materials (design docs, support tickets, etc). I have to do a lot of git archeology in my role, and this scheme regularly allows me to figure out why a code change was made years ago without ever talking to anyone.

          • AA5B@lemmy.world
            link
            fedilink
            arrow-up
            3
            ·
            5 months ago

            To be honest, when I ask a candidate about git, I’m looking for them to describe this workflow.

            Heck, I have a new person who I tasked with minor config change, just to make sure she knows how to use git in a professional environment

    • Ekky@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      19
      arrow-down
      1
      ·
      5 months ago

      “Fixed issue with ssl python libs,” or “Minor bugfixes.”

      Red bird going "Hahaha, No!"

      In other news, never work more than one person on a branch (that’s why we have them). Make a new related issue with its own branch and rebase whenever necessary, and don’t even think about touching main or dev with anything but a properly reviewed and approved PR (in case they aren’t already protected), or I’ll find and report you to the same authority that handles all the failed sudo requests!

      Also, companies that disable rebasing are my bane. While you can absolutely do without, i much prefer to have less conflicts, cleaner branches and commits, easier method to pull in new changes from dev, overall better times for the reviewer, and the list goes on. Though, the intern rewriting multiple branches’ history which they have no business pushing to is also rather annoying.

    • bleistift2@feddit.de
      link
      fedilink
      English
      arrow-up
      9
      ·
      5 months ago

      If it’s not in the git log, it’s not a comment.”

      This is so incredibly dumb, though I’m sure I don’t have to tell you this. That comment will be buried in the git log if anyone ever fixes a typo on that line.

    • Valmond@lemmy.mindoki.com
      link
      fedilink
      arrow-up
      9
      ·
      5 months ago

      Why does

      git rebase

      work sometimes?

      Yeah git can get quite complicated when there ate lots of people working on the same things.

      • mkwt@lemmy.world
        link
        fedilink
        arrow-up
        17
        ·
        5 months ago

        It’s not git that’s complicated. The work is complicated. git is just one of the tools that programmers use to manage the complexity.

        I also think that some people get too hung up on having a “clean” history, and trying to “fix” the history after it has already occurred. I usually have enough problems to worry about in the present, without also trying to worry about the past.

        • Wrench@lemmy.world
          link
          fedilink
          arrow-up
          7
          ·
          5 months ago

          I find the “clean history” argument so flawed.

          Sure, if you’re they type to micro commit, you can squash your branch and clean it up before merging. We don’t need a dozen “fixed tests” commits for context.

          But in practice, I have seen multiple teams with the policy of squash merging every branch with 0 exceptions. Even going so far as squash merging development branches to master, which then lumps 20 different changes into a single commit. Sure, you can always be a git archeologist, check out specific revisions, see the original commits, and dig down the history over and over, to get the original context of the specific change you’re looking into. But that’s way fucking more overhead than just looking at an unmanipulated history and seeing the parallel work going on, and get a clue on context at a glance at the network graph.

          • GissaMittJobb@lemmy.ml
            link
            fedilink
            arrow-up
            3
            ·
            5 months ago

            Using curated commits to optimize for pull request reviewability is highly underrated. Liberal use of interactive rebasing to ‘tell a story’, essentially.

          • andioop@programming.dev
            link
            fedilink
            English
            arrow-up
            2
            ·
            5 months ago

            you’re they type to micro commit

            Thanks for a much shorter and better way to explain this tendency of mine and why I rebase a lot, yoinking this phrase.

        • zqwzzle@lemmy.ca
          link
          fedilink
          English
          arrow-up
          5
          ·
          5 months ago

          I like to rebase on my feature branches before the PR because it’s a gift to my future self that resolves all the conflicts (if any) before my work goes in. I just find trying to figure out how those conflicts got resolved when there are a bunch of merges in more difficult if there’s a problem later. It’s easier to understand for me. YMMV, this does not work for everyone. Etc etc.

  • Cyborganism@lemmy.ca
    link
    fedilink
    arrow-up
    34
    ·
    5 months ago

    Once you understand that everything is similar to a tag, like branch names are basically tags that move forward with each commit, that HEAD is a tag that points to your current commit location in history, and what command moves what kind of tag, it becomes easier to understand.

    Suddenly having a detached HEAD isn’t as scary as you might think. You get a better understanding of fast forward merges vs regular 3-way merge.

    Also understanding that each commit is unique and will always remain in the history and can be recovered using special commands. Nothing is lost in git, unless you delete the .git sub-directory.

    • zaphod@lemmy.ca
      link
      fedilink
      English
      arrow-up
      13
      ·
      5 months ago

      For folks unaware, the technical git term, here, is a ‘ref’. Everything that points to a commit is a ref, whether it’s HEAD, the tip of a branch, or a tag. If the git manpage mentions a ‘ref’ that’s what it’s talking about.

      • Cyborganism@lemmy.ca
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        5 months ago

        Oh fuck. I didn’t think of that. Than you for reminding me.

        Edit: Ah but you can only run this in your local repo. If you happen to push anything, you might not be able to run it on the remote. Many DevOps platforms won’t allow it.

        • Doc Avid Mornington@midwest.social
          link
          fedilink
          English
          arrow-up
          2
          ·
          5 months ago

          Oh yeah, and anybody else who had fetched in those commits may still have them as well. It’s hard for something to be gone-gone, but it may be annoyingly-hard-to-recover-gone.

        • zalgotext@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          5 months ago

          Imma be honest I pulled that estimate out of my ass lol, but I feel like it was pre-pandemic? which would put it at at least 4 years ago and so holy shit I’m gonna go cry in a corner because it’s been 4 years since the start of the pandemic

      • throwwyacc@lemmynsfw.com
        link
        fedilink
        arrow-up
        1
        ·
        5 months ago

        Isn’t this only the case in github? All my repos are based from master, and I would assume that’s because I init on the command line and push up to the remote?

        • AA5B@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          5 months ago

          GitLab also changed a few years back. We host our own, so got the update later than people using the service … it was a bit of an argument at first since everyone wanted to stick with the familiar, but laziness won out. Unfortunately, it’s not really justifiable to go back and change legacy projects, so now it’s inconsistent

          • throwwyacc@lemmynsfw.com
            link
            fedilink
            arrow-up
            1
            ·
            5 months ago

            If you don’t have any scripts that rely on branch name it should be pretty trivial actually. But I wouldn’t be shocked if you had a few dozen scripts that nobody has looked at in the last century lol

            • AA5B@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              5 months ago

              The question actually came up for a new tool to help automate dependency updates. Do we need to change the config to account for the inconsistency?

              It turns out we don’t: it correctly uses the default branch, no matter what it’s called. However we had to consider the question. and investigate. It spent someone’s time

      • TunaCowboy@lemmy.world
        link
        fedilink
        arrow-up
        8
        ·
        5 months ago

        You should not be pushing into your main/master/whatever branch.

        All the main/master replies completely miss the point, further emphasizing sirsirsalot’s statement.

        • Hawk@lemmynsfw.com
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          5 months ago

          I think I’ll keep doing it. It’s worked fine for the past decade 🤷

          • Solemn@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            1
            ·
            5 months ago

            It works fine for small projects. I think that with more than 2-3 devs a PR based strategy works better for enforcing review and just makes life easier in general, since you end up with less stuff like force pushes to fix minor things like whitespace errors that break everyone’s local.

    • jxk@sh.itjust.works
      link
      fedilink
      arrow-up
      7
      ·
      5 months ago

      Me as an Emacs user, who omits -m on purpose to practice quitting vi in case I really need it

      • PotatoesFall
        link
        fedilink
        arrow-up
        6
        ·
        5 months ago

        you’re an emacs user who has vi set up as the default editor on your system?

        (You can change it altering the $EDITOR env var)

        • jxk@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          ·
          5 months ago

          I only use $EDITOR to launch vi from git. Emacs runs as a single process and is always open.

    • JATtho@sopuli.xyz
      link
      fedilink
      arrow-up
      4
      ·
      5 months ago

      The day I configured git to use Geany for commit messages with a separate config specifically tuned for this, it improved my life by 300%

      ~$ cat ~/bin/gitedit
      #!/bin/sh
      exec /usr/bin/geany -i -s -t -c ~/.config/gitgeany $@
      

      Then in git config: git config --global core.editor "gitedit"

    • Trollception@lemmy.world
      link
      fedilink
      arrow-up
      1
      arrow-down
      27
      ·
      5 months ago

      What developer uses Linux in professional work? Maybe for on the side stuff but I haven’t seen any corporate Linux machines.

      • aodhsishaj@lemmy.world
        link
        fedilink
        arrow-up
        9
        ·
        5 months ago

        Hello, I use a linux machine for dev work and all the servers and containers I touch are linux, all managed through gitlab CI/CD.

        git scm is my daily driver and I use it for not taking and documentation as well as active python development.

      • Ephera@lemmy.ml
        link
        fedilink
        arrow-up
        7
        ·
        5 months ago

        The entire IT ecosystem is built around Linux, because it’s so prevalent in servers, containers, budget hardware and the open-source community.

        Yes, many companies don’t understand that and expect their devs to be productive on Windows. But in my experience, that’s an uphill battle.

        In my company, we get very little IT support, if we decide to order a Linux laptop and we still have significantly less trouble with getting things set up to start coding.
        Not to mention the productivity boost from having all the relevant technologies natively available + being able to script whatever you want.

      • Solemn@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        1
        ·
        5 months ago

        Everywhere I’ve worked, you have a Windows/Mac for emails, and then either use WSL, develop on console in Mac since it’s Linux, or most commonly have a dedicated Linux box or workstation.

        I’m starting to see people using VSCode more these days though.

          • Solemn@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            3
            ·
            5 months ago

            I think someone else said what it actually is in another comment. It’s functionally identical 90℅ of the time for me anyway,and I use CLI and vim on it.

          • Ephera@lemmy.ml
            link
            fedilink
            arrow-up
            2
            ·
            5 months ago

            They’re both UNIX-like, i.e. they both implement the POSIX specification and are therefore in many ways compatible.

            But yeah, modern macOS is more directly derived from the original UNIX operating system.
            Linux was instead implemented from scratch to be compatible with UNIX.

  • Ohi@lemmy.world
    link
    fedilink
    arrow-up
    30
    ·
    5 months ago

    Aye, most of my 10 year career in web dev is pretty much those commands. However, some advanced git concepts are worth diving into. Stuff like git bisect that can narrow down the exact commit that broke your app is an absolute life saver. Knowing how to git cherry-pick is also a git skill professionals should be comfortable doing. Migrating work from one branch to another without merging the entire branch is pretty common.

  • gazter@aussie.zone
    link
    fedilink
    arrow-up
    17
    ·
    5 months ago

    As someone who knows that they know very little about git, this thread makes me think I’m not alone.

  • BehindTheBarrier@programming.dev
    link
    fedilink
    arrow-up
    13
    ·
    5 months ago

    I made do with my IDE, even after getting a developer job. Outside shenanigans involving a committed password, and the occasional empty commit to trigger a build job on GitHub without requiring a new review to be approved, I still don’t use the commandline a lot.

    But it’s true, if you managed to commit and push, you are OK. Even the IDE will make fixing most merges simple.

    • EatATaco@lemm.ee
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      2
      ·
      5 months ago

      These threads drive home the point that a GUI of some sort is far superior for most users. I use git kraken, but in the past I’ve used git extensions as well, and I take advantage of so much more git has to offer than pretty much everyone here.

      I swear people just want the cli to be better so they claim it is, but I really don’t get how. Especially for quickly scanning the repo, doing diffs, commiting partial files, history, blame, etc.

  • YTG123@feddit.ch
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    5 months ago

    Every once in a while, you can refresh your memory by reading the man page.

    Or if, like me, you use Emacs, Magit exposes everything quite clearly.