This is not only good software practice, but it will help us recover changes when necessary. The master branch is where we should keep all deployable, reproducible code. Anything in development should be on its own branches.
In this way, Neel, Neeraj, Corey, Aakash, and myself can all work on separate aspects of the codebase on our own branches, and PR these changes into master when they've been reviewed and won't break our reproducible analysis pipeline.
For instance, cleaning and tokenization might take place on a branch called clean-tokenize. When we're then working on joining geographic data and topic modeling (both of which are separate tasks), Neel and Neeraj can work on geo-data and topic-modeling respectively, submitting non-conflicting PRs when the work on these respective branches are complete. If we're just merging directly to master, this will not work.
See this article for more info and let me or Aakash know if you need a git branch tutorial.
This is not only good software practice, but it will help us recover changes when necessary. The master branch is where we should keep all deployable, reproducible code. Anything in development should be on its own branches.
In this way, Neel, Neeraj, Corey, Aakash, and myself can all work on separate aspects of the codebase on our own branches, and PR these changes into master when they've been reviewed and won't break our reproducible analysis pipeline.
For instance, cleaning and tokenization might take place on a branch called
clean-tokenize. When we're then working on joining geographic data and topic modeling (both of which are separate tasks), Neel and Neeraj can work ongeo-dataandtopic-modelingrespectively, submitting non-conflicting PRs when the work on these respective branches are complete. If we're just merging directly to master, this will not work.See this article for more info and let me or Aakash know if you need a git branch tutorial.