Ask them about their pain points when working collaboratively, especially when sharing code or text that incrementally changes. I'm almost certain that while sharing their experiences they'll come up with a reason on their own.
I've introduced the concept before as a security feature first. Because git will keep a history of your project, you can always revert, even if you mess up.
Try to keep the workshop itself pretty easy. Start off with how to use git for a single user (git add, commit, push). Then talk about how git handles multiple users (branches, merges). This would also be a good chance to ingrain some best practices into them, such as branches named after issue numbers. I would finally finish off with the fork/pull request workflow. (But only if that's something that could be common in your codebase.)
I'd be happy to talk to you more about this or share some ideas for the presentation if you want to get in contact with me directly!
Ask them about their pain points when working collaboratively, especially when sharing code or text that incrementally changes. I'm almost certain that while sharing their experiences they'll come up with a reason on their own.
I've introduced the concept before as a security feature first. Because git will keep a history of your project, you can always revert, even if you mess up.
Try to keep the workshop itself pretty easy. Start off with how to use git for a single user (git add, commit, push). Then talk about how git handles multiple users (branches, merges). This would also be a good chance to ingrain some best practices into them, such as branches named after issue numbers. I would finally finish off with the fork/pull request workflow. (But only if that's something that could be common in your codebase.)
I'd be happy to talk to you more about this or share some ideas for the presentation if you want to get in contact with me directly!
Thanks for the reply! I'll definitely talk to the engineers and try to show how Git can solve their problems.