NCEAS / sasap-training

Training agendas and materials for open science tools for SASAP
https://nceas.github.io/sasap-training
8 stars 6 forks source link

04-version-control #2

Closed ben-williams closed 6 years ago

ben-williams commented 7 years ago

Bryce - I know it is tough to convey - but showing "realistic" examples of collaborating using git/github would be greatly beneficial for any of my staff in attendance

mbjones commented 7 years ago

@ben-williams Thanks for the feedback. I mentioned to Rich the other day that I'd like to review the participants list with him and talk about how to best target the material. If you'd like to participate in that discussion I'm sure it would be valuable. We haven't scheduled a time yet, but planning for next week.

amoeba commented 7 years ago

Right there with ya, @ben-williams. That's the biggest thing that bugs me whenever I go to a git/GitHub tutorial. We only have an hour for the git/GitHub tutorial right now which will mostly only allow us to get through setup, init, commit, push, pull. Other stuff we may not be able to get to could include:

Of those topics, knowing which are of higher or lower priority could help.

As for making the tutorial relatable, I'm having a hard time coming up with an awesome example. I'm thinking of an analysis that is simple (i.e., <50 or <100 LOC) that uses a single CSV file as input. And then the task around that project could involve changing an assumption or the structure of a likelihood (instead of duplicating the code and commenting out the old bit) and committing the change with abandon because you're using git and you never need to comment out old code. Thoughts?

mbjones commented 7 years ago

Tags. I think they are key to getting back to versions of interest.

amoeba commented 7 years ago

I like that: Tags for versions included in annual assessments, AMRs, versions of assessments presented to plan team, etc.

ben-williams commented 6 years ago

Here is an early proto of trying to get multiple people, in various parts of the state, working on the same project simultaneously https://github.com/commfish/2016_survey/network

We had multiple branches and to avoid merge conflicts I designated non-overlapping analyses/writing to individuals. Getting everyone to regularly pull/push etc. becomes really important. Maybe showing what a merge conflict is and how to deal with it would be good? Or maybe that is too off putting for a starter!

amoeba commented 6 years ago

It might work! Due to the short time period I think we're going to focus on using git via RStudio which is about the worst git interface ever invented, and certainly makes it very hard to deal with merging. That said, handling merge conflicts (or avoiding them) is critical to actually using git to collaborate. Thanks for the example of how you've done it -- that's very helpful!

amoeba commented 6 years ago

Thanks for opening this issue @ben-williams. This prompted good discussion here and off-thread while prepping the workshop and I imagine we'll make use of what we've recorded here in future lesson development. Please re-open if you have any more good ideas like the ones above.