@norman70688 Huh, you're right. I thought those were all the same, but not exactly.
Thanks for the tip.

(And I would argue :x is actually better than :wq, since it doesn't​ save the file unnecessarily)

:x for a shorter way to do :wq

@ChainsawBaby @SHA-256 Also, you misspelled it.

Ouch. I've been there.

May I suggest more descriptive variable names, maybe?

@dreik Good luck on those last upvotes!

@dreik No problem friend! Glad I could help!

Not really, it still feels like magic.

Only most of the times it's the dark kind, that waits for you to get comfortable with it and then blows up on your face.

How is an interview sudden? Like, people break down your door, set up a whiteboard and demand you implement a bubble sort?

Still, best of luck!! Hope you get it!

@akd5010 That way they can spot more bugs.

The middle row bugs me a bit, though. Ruins the symmetry.

@dreik As I said, ask away ☺️
We use JIRA (from Atlassian) as our management system.
We don't assign time though, we just estimate complexity (we're using Scrum here). So, we have some baseline stories we use to anchor our estimations of new ones.
The only "technique" we use to estimate is Planning Poker, where every team member has a deck of cards with point values on them, and everyone shows their estimations at the same time (to avoid bias). If there are differences, we then discuss them to reach a consensus.

PS: I also heard good things about, but never tried, the Hamburger Method for splitting user stories better, in order to estimate them more easily: https://gojko.net/2012/01/...

Stockholm syndrome?

I would probably chase them down and make sure they understood the trade-off, or at least made a decision.

@dreik Well, ours is fairly straightforward.

We're using GitHub. There we have the "company" account (with restricted access), which has the production-ready code.
When working on a feature, a developer forks the appropriate repository, which creates a copy of the repository under their account. In that repo they do whatever they want (feature branching, etc.)
When a feature is completed, the developer creates a Pull request into the master branch of the "company" repository.
The creates pull requests then trigger the Continuous Integration flow (using teamcity) that will build th code and run all tests.
Once the code is reviewed the PR is merged and that triggers a deployment to the acceptance environment, followed by production.

You could also achieve the same under a single repo if every developer had their own branch(es) and *no one* pushed onto master.

Is that clear? Feel free to ask any questions, I'll be glad to answer them if I can.

@dreik It can still be good in a multi-person project, as long as everyone is pushing to their own branches (and amending, and force-pushing, etc) before pushing that work into the master branch (where others can get it).

At my current job each developer has their own repository (fork of the main one) and can only push changes to be released via a Pull request. Until that is merged, it's usually fine to fiddle around with history. After that, it's set in stone.

@dreik It's not hard at all. You just need to force push it afterwards (which is destructive and can screw stuff up if you're not careful).

The problem is if someone pulled those commits already. Then other people's local history will be different from the one in the remote repository, and git will throw a hissy fit when they try to pull the new changes.

@allanx2000 Ouch. I'm sorry 🤐

Deadlock

That looks unproductive.
I can only imagine the ridiculous amount of time all those ducks will take to reach a consensus on anything.

How is your week only getting started on a Thursday?

@theZorgEffect He did say they were minor...

¯\_(ツ)_/¯

Also, thank you devRant for finally giving me an appropriate place to complain about these things!

@SamGodDamn yup, I got the same!

Assistant TO the branch manager

Assuming they are hackers and save the data in a database, then they can say with 100% certainty that yes, your credit card number is in a hacker database.

So, you know, they're technically not lying.

@jerodev @JBSnorro @surgiie amend, with a backup of rebase in case he forgot?

Always test before committing.
But when that fails, rebase your commits to clean up your history.

(Disclaimer: I'm assuming this is git, since the screenshot looks like github)

@p0s1x Yeah, it wasn't eco-friendly at all. But it was effective. And the only time I did it (so far...)

@KnightsOfCode I'm not sure I follow. It was a separate branch, but the code changes still had to be reviewed anyway.

I'm so sorry 😞
Honestly, after having worked for over 3 years now at a company that does, I'll make an effort to never work at a place that doesn't have code reviews again.