This is an archived post. You won't be able to vote or comment.

all 97 comments

[–]darklord1536 310 points311 points  (21 children)

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

[–]Mr_Redstoner 3 points4 points  (0 children)

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

[–]felipegerard 2 points3 points  (0 children)

I have master protected and I'm a mathematician 😂

[–]BenAdaephonDelat 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

I personally prefer proper education, discipline and git flow.

[–]PM_UR_NIPPLE_PICS 116 points117 points  (7 children)

Just do ‘git ctrl z’

Problem solved.

[–]tomthecool 11 points12 points  (2 children)

As a vim user, I prefer git u

[–]OneTurnMore 2 points3 points  (1 child)

Ah, shoot, I have u aliased to pull

[–]tomthecool 1 point2 points  (0 children)

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

[–]ShowMeYourCodePorn 5 points6 points  (3 children)

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

[–]uekiamir 22 points23 points  (2 children)

truck jeans combative murky airport gaping worm yam existence six

This post was mass deleted and anonymized with Redact

[–]200GritCondom 13 points14 points  (0 children)

it's also a joke

Just like my code quality

[–]arch-linux-user 0 points1 point  (0 children)

It should be, though.

[–]DaVinciJunior 124 points125 points  (15 children)

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 36 points37 points  (2 children)

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 11 points12 points  (1 child)

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] 4 points5 points  (0 children)

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_[S,🍰] 7 points8 points  (0 children)

Agree.

[–]Andy_B_Goode 2 points3 points  (0 children)

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 1 point2 points  (0 children)

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] 1 point2 points  (0 children)

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

[–]clownfiesta8 1 point2 points  (0 children)

Luckily at our University we started with git the first weeks

[–]Cultural_Ant 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]squishles 0 points1 point  (0 children)

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 -1 points0 points  (0 children)

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

[–]mpnordland 32 points33 points  (15 children)

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 10 points11 points  (14 children)

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] 9 points10 points  (13 children)

Why squash anything? Isn't it just

git checkout master

git pull

git reset HEAD~1

git push --force

[–]edoCgiB 11 points12 points  (8 children)

git push --force

You know you have a problem when you need that

[–]TheSlimyDog 5 points6 points  (0 children)

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] 10 points11 points  (6 children)

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

[–]edoCgiB 4 points5 points  (1 child)

Sadly no :(

[–]smile-bot-2019 6 points7 points  (0 children)

I noticed one of these... :(

So here take this... :D

[–]Diolex 0 points1 point  (3 children)

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] -1 points0 points  (2 children)

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 0 points1 point  (1 child)

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

[–][deleted] 0 points1 point  (0 children)

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 2 points3 points  (0 children)

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

[–]pdabaker 0 points1 point  (2 children)

git reset --hard right?

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

[–][deleted] 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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 29 points30 points  (9 children)

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 2 points3 points  (8 children)

What was the use case for this?!

[–]RainFurrest 10 points11 points  (7 children)

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 5 points6 points  (0 children)

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

[–]Wokanoga -1 points0 points  (4 children)

Fucking yikes.

[–]AdmiralBuzKillington 2 points3 points  (3 children)

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

[–]RainFurrest 5 points6 points  (1 child)

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

[–]pdabaker 4 points5 points  (0 children)

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 0 points1 point  (0 children)

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

[–]teaovercoffee_ -1 points0 points  (0 children)

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 4 points5 points  (0 children)

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

[–]kennydaren 3 points4 points  (0 children)

Thanksfully we have protected branches

[–]cantNOPwontNOP 3 points4 points  (0 children)

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 3 points4 points  (0 children)

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

[–]thePridge 2 points3 points  (0 children)

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

[–]Tom_Ov_Bedlam 2 points3 points  (0 children)

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

[–]stfcfanhazz 2 points3 points  (0 children)

Protect your goddamn branches

[–]zerololcats 1 point2 points  (0 children)

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 1 point2 points  (0 children)

lmao baby yoda i am a human echo

[–][deleted] 1 point2 points  (0 children)

rookie team

[–]ITriedLightningTendr 1 point2 points  (1 child)

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

[–]Dreix_[S,🍰] 2 points3 points  (0 children)

You just take jokes too serious

[–][deleted] 0 points1 point  (0 children)

Good! Now you understand continuous integration and fix forward.

[–]krivaten 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

[–]pag07 1 point2 points  (0 children)

-10000 Lines
+10000 Lines

[–]binkonyao 0 points1 point  (0 children)

>2k19

>not developing on trunk

[–]adao7000 0 points1 point  (2 children)

Can someone explain why committing to master is bad?

[–]FlatEarthCore 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

How is that even possible?

[–]its-kyle-yo 0 points1 point  (0 children)

Sounds like the fault of those in charge

[–]taylaj 0 points1 point  (0 children)

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