This is a big challenge! It takes a while to navigate git un-destructively! There are some good resources out there, but the gist, at least of how I use git, is:
Avoid push -f, it's dangerous!
Prefer merge over rebase - this adds a lot of merge commits, but it makes working collaboratively much easier
Rebase master onto your branch early and often.
I'd love to know if you have any specific cases where your code gets clobbered by git. I run into them every now and then, but for the most part I manage to avoid it!
I think rebasing always feels painfully awkward and my brain doesn't quite understand what git is trying to do. Like having to fix the same conflicts over and over. Especially when you have multiple people working on the same branches or base branches it gets to be overwhelming fast.
I feel like I kind of get git, but I've been mostly using it as a glorified backup and "work on the same code on different machines" kind of tool, and definitely not to it's full potential.
I feel like I would need to actually use it as a collaborative coding tool before being able to fully grasp more of it.
While its true that git kind of demands you understand it on some level before it plays nice with you there are basically 3 things that will destroy work (And even then a wizard can perform a ritual to bring it back).
push -f If you get asked to do that its because you've done something to re-write history in a way that is inconsistent. Stop there.
rebase rebase is a command that allows you to re-write history. You'll see lots of advice to use it to clean up commits, or to do a pull --rebase. Either way, history is re-written. pull --rebase is actually pretty benign and can be used most of the time. When you get a conflict though, it can get messy as you'll be re-writing your already finished commits.
reset --hard <commit> This little one basically will have you go back in time. Harmless when you are using it on a commit that you haven't pushed. Uncool when you do it to commits that have already been pushed/pulled. It'll likely trigger a prompt to do a push -f
Git does take time to understand and get comfortable with. It supports a variety of workflows and styles. That flexibility often means its pretty confusing to get used to. For the overwhelming majority of use cases you'll rarely need any of the commands I mentioned.
Have you seen The Git Parable? It's a smooth read that explains why git does what it does pretty good. With that knowledge, you can use git more consciously i.e. less destructively.
I think next step to unlocking more of the power of git would be learning about branching strategies. Atlassian's and GitHub's articles are very informative. These are must-reads though:
git! Too often if I'm trying to do something tricky beyond the basics in git, it will destroy code somehow.
This is a big challenge! It takes a while to navigate
gitun-destructively! There are some good resources out there, but the gist, at least of how I use git, is:push -f, it's dangerous!I'd love to know if you have any specific cases where your code gets clobbered by git. I run into them every now and then, but for the most part I manage to avoid it!
I think rebasing always feels painfully awkward and my brain doesn't quite understand what git is trying to do. Like having to fix the same conflicts over and over. Especially when you have multiple people working on the same branches or base branches it gets to be overwhelming fast.
I feel like I kind of get git, but I've been mostly using it as a glorified backup and "work on the same code on different machines" kind of tool, and definitely not to it's full potential.
I feel like I would need to actually use it as a collaborative coding tool before being able to fully grasp more of it.
I agree with this. Once joining a project of 30+ devs, gits real power shines and I am slowly getting better at the more complex stuff.
While its true that git kind of demands you understand it on some level before it plays nice with you there are basically 3 things that will destroy work (And even then a wizard can perform a ritual to bring it back).
push -fIf you get asked to do that its because you've done something to re-write history in a way that is inconsistent. Stop there.rebaserebase is a command that allows you to re-write history. You'll see lots of advice to use it to clean up commits, or to do apull --rebase. Either way, history is re-written.pull --rebaseis actually pretty benign and can be used most of the time. When you get a conflict though, it can get messy as you'll be re-writing your already finished commits.reset --hard <commit>This little one basically will have you go back in time. Harmless when you are using it on a commit that you haven't pushed. Uncool when you do it to commits that have already been pushed/pulled. It'll likely trigger a prompt to do apush -fGit does take time to understand and get comfortable with. It supports a variety of workflows and styles. That flexibility often means its pretty confusing to get used to. For the overwhelming majority of use cases you'll rarely need any of the commands I mentioned.
Have you seen The Git Parable? It's a smooth read that explains why git does what it does pretty good. With that knowledge, you can use git more consciously i.e. less destructively.
I think next step to unlocking more of the power of git would be learning about branching strategies. Atlassian's and GitHub's articles are very informative. These are must-reads though:
Good luck!