I'm in charge of a new junior dev at work, who struggles quite a bit with git and has made some funny and weird mistakes. I'm now quite interested in knowing what are your WORST or BEST git/github fails 😈
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (19)
The biggest mistake you can make is not to commit. As long as you make regular commits you will always have the ability to time travel through the repo. So I'd say my personal biggest mistake is not even git init when I should have, or not commiting for a few hours.
Yup totaly agree, this is something my colleague struggles with.. And causes him loads of problems...
I sometimes forget, but I attempt to make commits as small as I posibly can, and not clutter PRs with to many changes at once, though it can be tricky
Id generally take too many commits over too few, It's easy to squash. Lately I've been leaving commits semi messy, and squashing when the pr is complete. It's rare that we scruitinize an individual commit in pr, but rather look at the whole diff on my team
Cool, I've been following a similar approach.
I encourage and prefer loads of small & descriptive commits, or not even that descriptive, just enough for me to understand the PR, commits + description. Then we squash the commits down to a more generalized one and clean up the commit description list (remove weird commits messages, fix typos, etc...) in the end I hope that if the squashed commit message is not understood, you got to the PR and check more in detail what has changed.
you mention a new to git user working on git collaboratively. How are they at rebasing or pulling in work that others have done. This is often hard to grasp.
Yeah, they're not that great... I'm always scared to let them pull in changes or interact with other peoples work.
Often times they have lost work while merging, most likely by error or because of lack of understanding. We tend to revise every PR and ensure no changes are lost without knowing, though soem stuff stills creeps through ocasionally.
Yeah, I think git in it's whole is kinda weird to fully understand or at least understand it enough to work eficiently initially.
After a while, at least for me, it makes so much sense I fail to relate with beginers... I try not to, but it's dificult for me... Like teaching to ride a bike, it's so obvious isn't it?...
I had a dev leaving the company. I instructed hime to setup git and we would put all of his side work into our central repo. we setup one of his projects, I left. He setup all of his other projects. came back the next day and git wasn't working. It appeared he had missed git init. This is there things went sideways. He continued to go ahead and git init, the somehow over the next day his entire project directory disappeard. I have no idea what commands caused this, but the history was wiped. He inadvertantly setup a monorepo wtih all of his projects as a submodule. This is not a situation you want to be in on your first day in git.
Lol, I can relate so much!!!!
It's like they summon whole new features xD
I've seen devs not understand branching get stuck in the situation where main is broken for weeks, stakeholders are asking for the data, but they can't run it because its broken. A minimal understanding of branching, or simply checking out an older commit is immesely valuable
Totally, I think good branching strategies and understanding can be almost the most important part of a healthy git repo.
Have you ever tried rebasing stuff to clear out bunch of unecessary commits from merges. Well I did but I did so with some features not ready for production. Also made sure to clean a history a bit because, why not. And puff, a week of fixing.
Best fail I don't know. Usually I have expert mode fu** ups
I get rid of unnecessary commits by Squashing them, as I explained in another comment.
I've never had such big issues myself, though I've had to scrap the whole repo and clone it again multiple times in my early days, not now though :P
Yeah that's a really nice thing to have, we have rules on our repos for this reason
It's saved us quite a few times
At the first phase of my programming career, I used to thik is that commit message values nothing and is only required to push something into repository. So, I had these bunch of commit messages that read "STUFFS" . Later I had to cherrypick specific commits in another branch and the rest is pain in the ass.
This is more of a funny one, that might have happened to some of you late in the day or at night
git commit -m "git push"I think my biggest mistake is using/recommending poor merge tools. I've settled on diffconflicts Plugin for vim as the intuitive and simple. Unfortunately vim is not something which goes anywhere if I recommend it.
I think there is a general mistake that takes time to get over. Not taking time to understand what you did. This applies to fixing bugs as using git.
Mess up a rebase -> force push -> oh no
i suggest if your on a group project write that are short but understandable that way the next person can undestnad what you did