Is it just me, or do programmers only come in “lightweight” and “Rivals Þor in trying to drink the oceans dry” varieties?

Somehow I manage to be both. My alcohol tolerance is very high (which is great… I like a little buzz but never want to be actually drunk), but for me, one toke is over the line.

I’m guessing you don’t mean commits that actually bring updates from a different branch in? I’m responsible for a bunch of commits that catch my feature branch up to main and a couple that bring my branches into main.

If we were working on the same project, what would you want to see for those? This is hosted on a private gh repo, but it’s a small shop and we were working on a tight deadline for an MVP release and were not using PRs for the stuff I was working on.

The boss (co-owner of the business) is the Sr dev on the project and until recently was the only sr dev in the whole shop. I actually don’t think he has experience with using git in a team context.

One of my other tasks is working on internal docs (which didn’t exist before I joined the team) that would include git best practices for branching strategies and commit messages, so I’m interested in what folks who have more experience than I do would like to see as I try to nudge the team practices.

Git won’t let the second person push if their commit history doesn’t line up with the origin branch.

It should be trivial to do a git pull --rebase to move your new commit after the upstream version, but as far as I can tell, no one on my current project remembers this (or perhaps they’re using gui tools or something). Our log is full of “merge origin/main onto main”.

I stand corrected. I haven’t used anything other than proton mail in a while and it works there. I thought it was part of the standard

Thankfully, a.ryan@example.com and aryan@example.com should be delivered to the same inbox.