1089
top 50 comments
sorted by: hot top controversial new old
[-] redcalcium@lemmy.institute 176 points 8 months ago* (last edited 8 months ago)

Interviewer: It's git push origin main now. Get out of here!

[-] seth@lemmy.world 168 points 8 months ago* (last edited 8 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?

[-] Michal@programming.dev 45 points 8 months ago

👆 This guy gits it

[-] redcalcium@lemmy.institute 38 points 8 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.

[-] fckreddit@lemmy.ml 35 points 8 months ago

Single person operation pushes directly to main.

load more comments (1 replies)
[-] MR_GABARISE@lemmy.world 10 points 8 months ago

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

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

load more comments (1 replies)
load more comments (10 replies)
[-] RustyNova@lemmy.world 24 points 8 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 36 points 8 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 24 points 8 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 14 points 8 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.

load more comments (3 replies)
load more comments (1 replies)
load more comments (5 replies)
[-] cyborganism@lemmy.ca 16 points 8 months ago

Just set your default behavior.

[-] OpenStars@startrek.website 26 points 8 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.

load more comments (9 replies)
[-] andreluis034@bookwormstory.social 69 points 8 months ago

I once had HR ask if I was familiar with G-I-T ( she spelled it out), for a moment, my only thought was "wtf is G-I-T".

[-] dQw4w9WgXcQ@lemm.ee 52 points 8 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."

[-] fahfahfahfah@lemmy.billiam.net 18 points 8 months ago

One of my first interviews in Canada I was asked what a “zed-index” is and was like what? A what now?

load more comments (1 replies)
load more comments (1 replies)
[-] punkwalrus@lemmy.world 67 points 8 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 49 points 8 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 31 points 8 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 20 points 8 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

load more comments (1 replies)
load more comments (3 replies)
[-] ekky@sopuli.xyz 18 points 8 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.

load more comments (2 replies)
load more comments (2 replies)
[-] Anticorp@lemmy.world 41 points 8 months ago

If you're pushing to master, then you're doing it wrong.

[-] zalgotext@sh.itjust.works 35 points 8 months ago

Yeah main has been the defacto default branch name for like half a decade now

[-] TunaCowboy@lemmy.world 15 points 8 months ago

git whoosh --hard

load more comments (2 replies)
load more comments (2 replies)
[-] Wilzax@lemmy.world 39 points 8 months ago

So do you guys pronounce it git or jit

[-] ikidd@lemmy.world 42 points 8 months ago

Is that what we're going to do tonight, we're gonna fight?

load more comments (1 replies)
[-] SpaceCowboy@lemmy.ca 20 points 8 months ago

I pronounce it the correct way you silly git!

load more comments (1 replies)
[-] 257m@sh.itjust.works 14 points 8 months ago

Don't start this. Its not like gif. Git is clearly pronounced like git. There is no possible argument you can make otherwise.

load more comments (1 replies)
load more comments (11 replies)
[-] cyborganism@lemmy.ca 34 points 8 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 13 points 8 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.

load more comments (4 replies)
load more comments (4 replies)
[-] ramjambamalam@lemmy.ca 33 points 8 months ago
[-] aeharding@lemmy.world 39 points 8 months ago* (last edited 8 months ago)

git: 'gud' is not a git command. See 'git --help'.

rekt

load more comments (4 replies)
[-] Ohi@lemmy.world 31 points 8 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.

[-] chicken@lemmy.dbzer0.com 31 points 8 months ago

If you happen to forget the -m though, you may also need to have mastered exiting vim

load more comments (15 replies)
[-] crony@lemmy.cronyakatsuki.xyz 21 points 8 months ago* (last edited 8 months ago)

Average linux user managing his dotfiles.

Yes I'm guilty of that, only thing more I know is creating new branches.

[-] SomeBoyo@feddit.de 20 points 8 months ago

git blame is another good one

load more comments (1 replies)
[-] gazter@aussie.zone 17 points 8 months ago

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

[-] laurelraven 21 points 8 months ago

I think advanced git knowledge, like RegEx, is the exception, while the norm is to know the tiny handful of day to day useful bits

[-] lhamil64@programming.dev 11 points 8 months ago

How is regex git knowledge? I guess you can use regular expressions with git grep but it's certainly not a git-oriented concept...

[-] MrRazamataz@lemmy.razbot.xyz 17 points 8 months ago

what. that's not what they said. they are comparing git knowledge to regex knowledge.

[-] Astongt615@lemmy.one 10 points 8 months ago

Ah, thanks for the explanation. I too misunderstood the inflection.

load more comments (1 replies)
load more comments (6 replies)
[-] Ephera@lemmy.ml 14 points 8 months ago

Well, if anyone wants to learn more about Git, I can recommend this: https://ohmygit.org

load more comments (1 replies)
[-] BehindTheBarrier@programming.dev 13 points 8 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.

load more comments (1 replies)
[-] ytg@feddit.ch 13 points 8 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.

[-] darkpanda@lemmy.ca 12 points 8 months ago

Learn to use git bisect. If you have unit tests, which of course you should, it can save you so much time finding weird breakages.

[-] xthexder@l.sw0.com 11 points 8 months ago

With automated CI, I've had very few times where bisect is useful. Either the bug was introduced 1-2 commits ago, or it's always been there and the exact commit is irrelevant to the solution, since you just fix it forward.

[-] go_go_gadget@lemmy.world 11 points 8 months ago

Woah look at mr. fancy pants with his git push arguments.

load more comments (1 replies)
load more comments
view more: next ›
this post was submitted on 03 Mar 2024
1089 points (100.0% liked)

Programmer Humor

19529 readers
397 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS