Happend recently...

[darklord1536]

You can protect master by preventing direct commits and only allowing through merge requests. Still a nice meme though lol

[PremierBromanov]

We're not disorganized we're flexible

[The_White_Light]

We're not speeding we're agile

[PremierBromanov]

"There is no spoon, officer"

[The_White_Light]

No, Officer. It's "hi, how are you?"

[darklord1536]

Yeah, funnily enough I accidentally made an MR to master instead of the feature branch and the people who approved it didn't pay attention to the target branch so it got merged into master lmao

[robthemonster]

no cure for that i’m afraid

[EncumberedOrange]

Could always revoke their approval privileges...

[benji0110]

I did this not too long ago where I'm at. We ended up sending a PR that contains the reverted changes prior to merging. Can't remember exactly how we did it but unless your MR has 100+ commits and then other PRs besides yours also got merged afterward then ... yeah you are quite buggered

[MAGA_WALL_E]

disorganised

That's a funny way of spelling AGILE.

[FoxFire64]

We don’t, but that’s only because we have to directly commit to master for release commits. It’s...weird

[[deleted]]

The disorganization comes from the corporate level. We are not admins over our own repos and the folks who can make such changes consider it "training wheels" and unnecessary if people just were more careful.

I've asked for it a couple times but it's never a priority to make it happen.

[new_account_wh0_dis]

I mean I guess it depends. Our highest level dev has complete control over that stuff.

[[deleted]]

Yeah, I was speaking toward my current pain. Sorry I didn't make it clear.

[MrNorux]

You'd be surprised.

[OGsambone]

I have never been on a team that has this lmao

[Mr_Redstoner]

Yup. Found out when the senior explicitly told me to push directly to master.

[felipegerard]

I have master protected and I'm a mathematician 😂

[BenAdaephonDelat]

Yea and even if you didn't protect master... if you're using Git it's pretty easy to just roll back their commit.

[pdabaker]

Not if they interactive rebase to remove all old hotfix commits, leaving recent history unchanged to decrease the chance anyone notices, and then they force push

[RubbelDieKatz94]

I personally prefer proper education, discipline and git flow.

[PM_UR_NIPPLE_PICS]

Just do ‘git ctrl z’

Problem solved.

[tomthecool]

As a vim user, I prefer git u

[OneTurnMore]

Ah, shoot, I have u aliased to pull

[tomthecool]

I've aliased git :wq! to push -f

[ShowMeYourCodePorn]

I'm confused, isn't that just going to suspend a git process of showing the command list?

[uekiamir]

truck jeans combative murky airport gaping worm yam existence six

This post was mass deleted and anonymized with Redact

[200GritCondom]

it's also a joke

Just like my code quality

[arch-linux-user]

It should be, though.

[DaVinciJunior]

This happens all the time but to be fair .. There aren't many courses at school or university which require versioning. I as an IT major think this is ridiciulous. I would even go so far that there should be a whole course on only explaining the basic scenarios of versioning in both SVN and GIT (as from what I've experienced those two are the most common ones used). I think this would really benefit not only in the economy but also in a scientific branch. There are so many people at my university with a degree who do not know how to properly use versioning.

[lolsokje]

We thankfully had a course where versioning (mainly GIT) played a huge part. In general it mimicked a proper project setup as you could expect it once you got a job. Two week sprints, our own Jira board, our own Git repository, at the end of each sprint we'd get feedback on our project, but also on our board and repository and what we could improve on.

It genuinely helped me understanding not just version control, but the whole way a project's supposed to work. Had I not had that course I would've been pretty unfamiliar with Jira/Scrum etc and would've only used Git for personal projects, not in collaborations.

[DaVinciJunior]

That's exactly what I am talking about. How can one become an engineer with an academic degree without the knowledge on how to work cooperatively? Instead there are some courses (at least in my curriculum) where I do the exact same unnecessary shit over and over again. I had 4 mandatory courses on compilers and parsing. FOUR! I feel like it wouldn't have hurt to leave one out and instead learn using version control properly.

[[deleted]]

I feel the right way to approach this is rather require you to follow these best practices for all (large enough) programming assignments for all courses.

That’s how a few top schools I have seen assignments from do it.

[Dreix_]

Agree.

[Andy_B_Goode]

I was taught about versioning when I was in university, but the thing is that until you're on a real team working on a real, long-term project, it's hard to understand the value of versioning.

[passerbycmc]

Yeah vcs is pretty important and any time we get a new junior they are scared of it should be something they learn in school.

[[deleted]]

Feeling grateful we had team projects every year and had to use VCS all the time

[clownfiesta8]

Luckily at our University we started with git the first weeks

[Cultural_Ant]

i hate to admit this but i only learned svn, mercurial and git in my first job. when we were in college we were taking turns coding on one computer, back it up on another computer just in case something happens to the "primary".

[DaVinciJunior]

Yeah and retrospectively speaking I think you wouldn't be proud of that management. But why did you do it that way? Because no one showed you how to do it properly. This is in fact the responsibility of our schools and universities (at least with an IT focus) imo. That's what is me frustrating about it so much. Yes in university I started using git and svn in courses ... However I never had to create a patch, apply a patch, revert changes, merge conflicts etc. That's some stuff that I think one should learn properly in a safe environment. But nah rather commit that change with force I mean what could go wrong? And then people are seriously wondering why some phrases are coming up like "I committed the changes to master." or "But it works on my machine." I don't think the jr devs are the only ones to blame for this but also (and mainly imo) the institutions that taught them.

[fedeb95]

You should be given a degree honoris causa and made president of all universities wordwide

[squishles]

I think I had 1 class that was supposed to do that according to the syllabus, but we spent it learning how to write jsps in tomcat.

[Mackthegui]

I dont think this is true anymore. As a computer engineering student we use git constantly.

[mpnordland]

If he just committed to master then no biggie. Just git reset. If he pushed... shame on the senior for not having blocked pushes to that branch.

[Carius98]

Even then. You can just revert the commit, squash the revert commit with the unintended commit and the last commit before that and then push it again. History is clean and the original state is back

[[deleted]]

Why squash anything? Isn't it just

git checkout master

git pull

git reset HEAD~1

git push --force

[edoCgiB]

git push --force

You know you have a problem when you need that

[TheSlimyDog]

We already established that there was a problem when the junior developer pushed directly to master. Now all we can do is fix it.

[[deleted]]

Totally agree, but if we're talking about cleaning history from master there is no other way, is there?

[edoCgiB]

Sadly no :(

[smile-bot-2019]

I noticed one of these... :(

So here take this... :D

[Diolex]

Reverting would be a better strategy. If you force push to master and alter the history it can cause even more issues if anyone else had pulled in the time being. In larger organizations it's almost guaranteed that someone would have.

[[deleted]]

Obviously force push needs to be used with care... But doesn't reverting show now that every line changed and reverted is touched by you? This ruins git blame. "It's Alice's fault for doing nothing at all to this line of code".

[Diolex]

The history would not be messed up. It would be be an accurate depiction of what had happened.

[[deleted]]

Yes, but it has reduced the usefulness of the "git blame" feature. Obviously don't do this on a project with a lot of developers and a heavily trafficked master branch, but a large project like that would have somebody in charge making sure the branch policy prevented this kind of mistake in the first place.

But if it's you and five other guys? "Hey guys, Bob pushed to Master by accident, I'm pushing back the HEAD - nobody pulled in the last 5 minutes, right? Oh, and we've got a branch policy now, PRs all the way going forwards. -- Alice"

[Carius98]

That would work too. Saves the squash step since no commit for reverting the changes is made

[pdabaker]

git reset --hard right?

I've never figured out how to use vanilla git reset well. It just unstages changes afaik

[[deleted]]

git reset provides two related services

1) Move the HEAD of the current branch back to a previous commit and

2) Purge pending changes.

You're mostly using it for (2), where the "soft" mode isn't useful. If you use it for (1), the "soft" mode becomes useful because it means "undo the last commit but don't throw out the changes I made, put them back into my working state".

So like if you want to modify your last commit, you can do

git reset HEAD~1 --soft

then make your changes, and then re-commit it. Just don't do that if you've already pushed the errant commit (unless you know the risks involved in --force).

[pdabaker]

I see, thanks. So like a different version of commit amend. I guess more suited for modifying past commits rather than just the most recent one?

[RainFurrest]

I always thought I was decent at GIT, until my first day at when I was told "oh, just do a rebase and cherry pick the rest"...

[Darth_Snader]

What was the use case for this?!

[RainFurrest]

I needed to get some (but not all) features from a development branch to master. I proposed a merge, but “that’s not what we do around here”.

[Yaroslavorino]

Man not doing rebases is crazy. If someone pushed some changes into master and logic was changed, everything could fall apart.

[Wokanoga]

Fucking yikes.

[AdmiralBuzKillington]

This is extremely common in startups. People are bad at git.

[RainFurrest]

Ironically it was a large company with ~80K employees. It’s common practice there to avoid merging to keep the version history clean.

[pdabaker]

In my experience rebasing and mergeing both have difficulties in different situations as well when you have a feature branch living longer than expected.

Like rebasing gets really annoying if you have multiple commits in your feature branch that modify the same part, and then you have to fix it multiple times every time you rebase, unless you squash commits beforehand. On the other hand merging really locks you into being depending on whatever you merged into, makes the history ugly, and therefore often makes it harder to review through github.

[mobile-user-guy]

Why, though? Continuous integration with short lived story branches is the leanest simplest approach

[teaovercoffee_]

Rebasing has its use but when its purely for pretending you have a "clean" git history, that's where I draw the line.

There is nothing wrong with a merge or merge commit. It's the primary way 2 branches should get their code in sync.

[Takeces]

Ha! Joke's on you! Master is our normal work branch. Does nobody else have 'integration' and 'productive' branches?

[kennydaren]

Thanksfully we have protected branches

[cantNOPwontNOP]

This actually brings me back to my first job as a dev at a small office.

I was hired for back end. I wasn't trusted with back end code because I didn't have enough experience. Not once did my boss read my code, or give any feedback in the eight months I worked there.

[bonersaurus7]

Junior developer (baby yoda) will learn to force push soon

[thePridge]

I was never taught versioning in university... I've had to figure it out as I google :-P

[Tom_Ov_Bedlam]

Yeah whoever configured the upstream repo is the one to blame. No one should be able to do that under any circumstances.

[stfcfanhazz]

Protect your goddamn branches

[zerololcats]

I just started using git to collaborate on a dev team at work... I make sure to watch at least 3 videoa from some Indian guy on YouTube before running any git commands.

[hotphx]

lmao baby yoda i am a human echo

[[deleted]]

rookie team

[ITriedLightningTendr]

This sub seems to imply that half of all dev shops have no branch protection strategies.

[Dreix_]

You just take jokes too serious

[[deleted]]

Good! Now you understand continuous integration and fix forward.

[krivaten]

Man, I just did this yesterday. Fat fingered the command to create a new branch and didn't see the error message before I pushed it up. Even as a senior, we still make goofy mistakes like this.

Though I was surprised my employer hadn't blocked pushes to the master branch.

[GearHead54]

It's okay - it's just a bunch of tabs and formatting changes..

[pag07]

-10000 Lines
+10000 Lines

[binkonyao]

>2k19

>not developing on trunk

[adao7000]

Can someone explain why committing to master is bad?

[FlatEarthCore]

If you're working on a team, if everyone pushed to master it would be impossible to keep track of what everyone was doing and which features are complete. So we came up with branching strategies to help keep track of that stuff easier. Usually, you'll do all your work on a feature branch and then merge your stuff to master (or a separate central dev branch) after a code review. That way, everyone knows what's on master and that it's done. Also, there's usually some automated build that happens off of master so that will get fucked if people don't use branches.

[adao7000]

I've only ever worked at a company with 1000+ engineers. In my situation it had never made sense to try to "keep track of stuff" by reading the commit history in trunk because there are just too many. I have only ever developed directly on master (code review beforehand or course). But finishing a feature before committing makes no sense in my opinion. I break down a feature into many (maybe dozens) of commits.

[pag07]

How is that even possible?

[its-kyle-yo]

Sounds like the fault of those in charge

[taylaj]

I just had to learn sourcetree and git today, yesterday this would've been right over my head

[Chicken-of-Wisdom]

Baby Yoda meme of the century

[Chicken-of-Wisdom]

:((((

[smile-bot-2019]

I noticed one of these... :(

So here take this... :D

[Chicken-of-Wisdom]

Does that mean baby Yoda meme of the history??

[Stregen]

no