Je cherche à vous aider à atteindre vos objectifs #code en #français . My goal is to help you work faster by sharing what I know about #SQL, #Python, and #Salesforce in #English and #French
I think people are definitely excited about the promise of:
More granularity about who changed what when
... backups? I haven't actually been on the team long enough to know if it's already backed up through other means (e.g. some sort of simple nightly clone), and if this would just be a different sort of backup
Everyone seems to be pretty open to it, so to me, what I guess I'm really hoping to get a better sense of is "Git workflows and concepts that might ease our lives."
I think "foolproofing" is a good part of a smooth transition. The easier it is to avoid getting into pickles that require people who don't know Git to spend an afternoon researching Git, the better.
Sort of like when I suggested to my colleague, "Hey, what if we taught everyone to hard-reset before they muck around, so it feels more like a slightly-convoluted SFTP upload than a whole new concept?"
Only I don't actually have experience to know if that is a good idea.
For the your query about the merge issues, you could look at a workflow like Git Flow to ease the problem of having messy merges.
Each update lives on its own feature branch (feature/my-update etc.) which is merged into develop when completed - if you have people working on files simultaneously the most you need to do usually is make sure you git pull and git merge develop into your feature before PRing. Features are cheap and offer a lot of the benefits you've mentioned above about granularity.
Im not sure if it's 100% relevant to your use case, and I'm not a git jedi by any stretch of the imagination, but if you have questions about this, I'd be happy to try and answer.
Je cherche à vous aider à atteindre vos objectifs #code en #français . My goal is to help you work faster by sharing what I know about #SQL, #Python, and #Salesforce in #English and #French
I think people are definitely excited about the promise of:
Everyone seems to be pretty open to it, so to me, what I guess I'm really hoping to get a better sense of is "Git workflows and concepts that might ease our lives."
I think "foolproofing" is a good part of a smooth transition. The easier it is to avoid getting into pickles that require people who don't know Git to spend an afternoon researching Git, the better.
Sort of like when I suggested to my colleague, "Hey, what if we taught everyone to hard-reset before they muck around, so it feels more like a slightly-convoluted SFTP upload than a whole new concept?"
Only I don't actually have experience to know if that is a good idea.
So looking for ... the actual good ideas. :-)
For the your query about the merge issues, you could look at a workflow like Git Flow to ease the problem of having messy merges.
Each update lives on its own feature branch (
feature/my-updateetc.) which is merged intodevelopwhen completed - if you have people working on files simultaneously the most you need to do usually is make sure yougit pullandgit merge developinto your feature before PRing. Features are cheap and offer a lot of the benefits you've mentioned above about granularity.Im not sure if it's 100% relevant to your use case, and I'm not a git jedi by any stretch of the imagination, but if you have questions about this, I'd be happy to try and answer.
Thanks; this is exactly the kind of comment I was hoping to hear! Will read this doc and practice a bit ... maybe on my next updates to my blog.