Hi Johnny, this was the one I took, Git started with GitHub. I don’t have other Git courses I have taken to compare it to, but I found the information easy to understand, and I felt I was given enough of it to give me the confidence to start using Git. When I asked a question to the instructor via Udemy I got a response very quickly - indeed it was the instructor, Jason, who mentioned BitBucket to me, another online Git repository, but without the need of making your repositories public (at least for individual usage, would need to check for teams etc).
In my previous roll as tech manager I had a group of 8 devs, they were split in to two squads of 4. This was a step forward from how the team worked years before, individually, as we just had many silos of information rather than information being spread across the team. I introduced a trigger point system, it was simply a date which went on the shared calendars, at this point or as close to it as practical, one team member from each squad moved to the other squad. This enabled my team to ensure that they got to work with everyone. If there were people you didn’t always get on with it was a way to move away from them for a period of time, if there were people you were close to it ensured that you did have to work with other people to - above all it ensure that more people started to become familiar with the variety of projects that, as a team, we had created. The trigger points in our case were at quarterly intervals which could be adapted obviously in this scenario.
You could still achieve this. If you have broken down the work into features, then the life span of the project should simply be feature x development duration (whether it’s fortnightly, monthly, two monthly) - it would still give an overview of the total amount of time. It also gives you the flexibility to adjust the development duration over time if, say 1 month is too long / too short etc.
That would indeed be very cool to see
Anyway, all of the above are only suggestions, not trying to say how to do it, just offering some thoughts on what may work. It will invariably be an experience in both overseeing/managing a collab project with remote participants of varying experience(s) and working in one, something which over time I’m sure will raise a significant number of things that worked well and things that could be improved.