Programming as a career

but if you squash your commits what will happen to your profanity-laden commit messages that end up here https://twitter.com/gitlost

Whats all the squash talk? Can't you just not allow the PR until its been squashed

We mostly PR directly on to master, ideally with few commits but I just reset and then PR with just the one commit (in theory not always in practice)

Yeah I commit until the cows come home into a feature branch, then squash the feature branch into dev. (I use Bitbucket to do this so there is little chance for human error.)

the trouble is the ideal number of commits to actually land for review is likely (imo) somewhere in between 1 and n

that said I don't really bother anyone I currently work with about this b/c our practices are bad and I'm still relatively new and don't want to waste my energy telling people to be better if they don't already value it

this is why when you "google in the gaps" on git you get three answers with all of them telling you definitely not to do what the other two say.

is version control hard or is git terrible? ('both' is an acceptable answer.)

You get better at googling though! Or maybe more accurately you get better at breaking down the bits so you're googling for smaller steps instead of "how do I build a moon"

I feel like git is as easy or as hard as your team makes it. I only really ever run add, commit, pull, push, merge, branch, checkout, and reset

ime it's beloved of people who like to over-complicate everything they do.

our default at work is to squash merge from feature branch into master. that way you don't get all the 'i'm trying this' or 'changed a thing' commits. before github there weren't feature branches...

I am lazy and just use a GUI

I do my adds and commits from the button inside vscode! the others from terminal

I think it would be cool to work at a shop where people had time to worry about things like squashing commits to make the log look nicer. Our logs look like a tire fire.

to be fair the only times I use git are for projects that don't remotely care about this, or for my own personal projects

git is good but has way too many options so takes forever to learn.

And then there are current best practices but some people didn't upload their brains so are still stuck on outmoded best practices.

goddam I really messed up this whole career thing lol

crushed some SQL today lads

xp -- this isn't career stuff, the only code I've done in the past month is a dumb reverse engineering project

lol sorry that was just a general scream into the void

Scream away!

I was scanning over my old posts, and I'm kind of stunned at how far I've come. Granted, that was (yikes) more than 10 years ago, but the industry's changed a load too, especially with the rise of bootcamps. I think those alone would've helped me out back then, and they're probably the best avenue for people thinking of getting into industry as a part of a career change.

I am proud to have leapfrogged from bash scripts into management like the ambitious careerist motherfucker that I was raised to be

Or basically “I realized I sucked at code so I volunteered for everything else I could do until it worked”

volunteering to do things where you've found a strength is seriously underrated and doesn't work in all organizations, but it's a good strategy

git is good but has way too many options so takes forever to learn.

I think git is great but to me its very much a secondary thing, I don't want to do anything more than the 8 or 9 commands I use. And if I found I was doing anything more than that I would wonder what had gone wrong that I needed those things.

Although hmmm, having said that github actions might be something worth looking into one day

I’ve done some vile things with git

surprisingly, vilegit.com seems unregistered

a foul repository

I am surprised vilegit.com hasn't been snapped up by VI purists

I am a vim purist but I stopped haranguing people about it 10 years ago

Some helpful but less-trafficked git commands that I use:

git ls-files -m

git add -p /path/to/file

My most recent git discovery was -v on git commit (which I’ve now made the default behaviour). It appends the diff (along with the list of staged and unstaged files) in your editor when you edit the commit message. It’s in the commented bit so it doesn’t go in the commit message but it’s useful to refer to, and most useful for catching stuff you shouldn’t be committing.

Oh, nice!

git add --patch whatever.js

is essential for a hygienic commit log

Thanks for the reminder! Any pro tips for using stash?

I always forget stash options so I have to look it up every time:

https://stackoverflow.com/a/10726185
https://stackoverflow.com/questions/3573623/is-it-possible-to-preview-stash-contents-in-git

And a whole bunch here!

https://www.freecodecamp.org/news/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a/

Thanks. Have also started using “git stash push” so that I don’t stash everything, just the files that are causing a merge conflict, say.

Wow just found out you can stash hunks as well.

If that's what you're into.

Lol

And now I have an even dorkier d/n.

https://i.pinimg.com/originals/7f/cd/36/7fcd3690d0e1b184c2d8d9fef6cbac98.gif

If only!

I'm learning tmux now!

[
git add --patch whatever.js
]

is essential for a hygienic commit log

i visit this page once or twice a month:

https://sethrobertson.github.io/GitFixUm/fixup.html

neat

I decided at some point that I hated trying to remember command line options and started using GitExtensions as my Git IDE; I have never looked back.

Sourcetree is nice on Mac.

not found anything decent on linux yet. and the one i did like (gitg) lost a lot of the things i liked about it from one version to the next (and gets confused by binary files, like 100% cpu confused)

(svn is generally better for my use case anyway - large document, lots of tiny changes - than git anyway because it stores the diffs and not a complete copy of each like git does*. i had a git directory that was 40x the size of the original document once)

(* git will compress eventually, i'm told, and i'm sure i could force it to happen faster than it does, but svn does it by default)

We onboarded a new hire recently who came from a bootcamp, and I realized that of our entire engineering team at the local office (we have presences in multiple regions), only our VP and lead security guy and our worst (by far) developer have CS degrees. That leaves a director, a devops lead (who has an EE degree), and two senior engineers (including me).

Actually the other senior eng has an interdisciplinary degree that can definitely fall under the CS heading.

aren't you the one who was trained not to say 'onboarded' though