DEV Community

loading...

What are your WORST git fails?

Keff
・1 min read

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 😈

It can be anything from a typo to a serious problem.

Discussion (19)

Collapse
waylonwalker profile image
Waylon Walker

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.

Collapse
nombrekeff profile image
Keff Author

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

Collapse
waylonwalker profile image
Waylon Walker

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

Thread Thread
nombrekeff profile image
Keff Author

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.

Collapse
waylonwalker profile image
Waylon Walker

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.

Thread Thread
nombrekeff profile image
Keff Author

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?...

Collapse
zyabxwcd profile image
zyabxwcd • Edited
  • I used to forget taking a pull from the remote before starting out to work on a feature which led to more chances of a merge conflict happening later on.
  • I struggled with rebasing while squashing commits. I still dont prefer rebasing. I did something I still dont understand which led to repeated commits in the same branch and then I altogether left that branch to die and later deleted it.
  • I have mistakenly tried to push directly to main branch but thankfully when working in a live project, it was setup in a way that it didn't allow me to do that. :)
  • I started working on a different feature in a branch that was for a different feature and committed the code in that branch.
  • And yes I have once pushed API keys that were exposed in the code to git.
Collapse
nombrekeff profile image
Keff Author

I have mistakenly tried to push directly to main branch but thankfully when working in a live project, it was setup in a way that it didn't allow me to do that. :)

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

Collapse
greenroommate profile image
Haris Secic

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

Collapse
nombrekeff profile image
Keff Author

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

Collapse
waylonwalker profile image
Waylon Walker

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.

Collapse
nombrekeff profile image
Keff Author

Lol, I can relate so much!!!!

It's like they summon whole new features xD

Collapse
waylonwalker profile image
Waylon Walker

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

Collapse
nombrekeff profile image
Keff Author

Totally, I think good branching strategies and understanding can be almost the most important part of a healthy git repo.

Collapse
jessekphillips profile image
Jesse Phillips

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.

Collapse
kingleo10 profile image
Niroj Dahal • Edited

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.

Collapse
nombrekeff profile image
Keff Author

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"

Collapse
aghost7 profile image
Jonathan Boudreau

Mess up a rebase -> force push -> oh no

Collapse
aheisleycook profile image
privatecloudev

i suggest if your on a group project write that are short but understandable that way the next person can undestnad what you did