👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
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.
👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
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?...
👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
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
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
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?...
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.