Create README.md

[rileyhgrant]

Create a README.md file. This helps new developers or curious users understand some basic facts about the repository.

Using Git, create a feature branch, add the new file and make any changes in this branch, then open a Pull Request that includes the addition of that README.md file. (Any time you push any changes on a local feature branch to the repository with git push, the GitHub repository here should recognize that and display a banner prompting you to open a pull request right then and there)

Some good things to include in the README.md would be:

• Project title (Genetic Prevalence Estimator, GeniE)
• A brief description of what this website aims to do
  • The website itself has a good little blurb on the about page
• A direct link to the live website
• A section directing users to CONTRIBUTING.md should they want to contribute

Here are a few repos with READMEs for reference, if needed

• https://github.com/broadinstitute/gnomad-browser
• https://github.com/prettier/prettier
• https://github.com/broadinstitute/cromwell

In a bit more detail:

1. Using git, when on the main branch, create a feature branch to store your changes. Something like git checkout -b jl/create-readme will create a branch called jl/create-readme
2. Use git branch -v to ensure you're on your feature branch, and not main. The branch you've currently checked out will have an * to the left of it.
3. Create a README.md file in the root of the directory. Add any and all content you desire.
4. Commit the changes (git add README.md)
5. Push the changes, to let the remote Repo know about them. The first time you push to a new local branch after creating it, Git will prompt you to set the default remote branch for your local branch, the command it suggests will look something like git push --set-upstream origin jl/create-readme and is just what you want)
6. After pushing your changes, check this GitHub repository. There should be a banner prompting you to open a pull request, hit the button to do so.
7. Write whatever you want in the description of the pull request, and open it using the UI.
8. Add yourself in the assigned section, and me (@rileyhgrant) as a reviewer on the PR.
9. Celebrate! Now you wait for me in this case, or in general whoever is assigned review, to review your PR and give you feedback

[rileyhgrant]

Hi @josephinelee1234, I just added you as an assignee on this issue. This is both a worthwhile piece of documentation, and an opportunity to get you more comfortable with how GitHub is used for projects with collaborators, if you haven't used the Feature Branch workflow before. If you have, then it's good review!

I've outline the steps to go through the Feature Branch workflow (create your own branch off main, perform any edits in your feature branch, then open a Pull Request (PR) to have your changes incorporated in main). This workflow helps ensure that clean commits are the only things that make it into the main branch.

Further, in this case, I believe there is some CD set up that will trigger an auto deploy upon any commit to main. Thus, it is advantageous to be able to choose when to rebase commits into main so that we can decide when we want to deploy code to production.