GitHub Education and Copilot Student for Bioinformatics

Use this short lab to apply for GitHub Education, check whether the Copilot Student benefit is available, and practice reviewing an AI-generated change without putting research data or credentials into an assistant.

1. Apply for GitHub Education

1. Sign in to your personal GitHub account and open Education benefits.
2. Choose Start an application under GitHub Education and follow the form. GitHub lists a current school ID, class schedule, transcript, or enrollment-verification letter as possible evidence.
3. Follow the email instructions shown for your institution. GitHub tailors its process: some applicants must add and verify an academic email; a .edu address is not a universal prerequisite. If your institution does not issue one or its domain is not recognized, follow GitHub's documentation and support route.
4. Submit the application and wait for a decision. Do not assume that submitting documents means you have been approved.

2. Activate Copilot Student after approval

GitHub says verified students can access Copilot's student benefit for free, and it reevaluates student eligibility monthly. Verification does not itself complete Copilot activation.

1. In Education benefits, find Free GitHub developer resources for students and teachers, select Learn more, and follow the activation prompts.
2. Review the Copilot use-policy choices during setup. One setting controls whether suggestions matching public code are allowed or blocked. If you allow matching suggestions, inspect any displayed match details and assess licensing and attribution before reuse.
3. If verification is approved but settings still show Copilot Free, a trial, or paid checkout, allow time for the benefit to apply. GitHub says this can take several days. Retry from Copilot settings or the Education benefits page; do not purchase a plan just to resolve the delay. Contact GitHub Support if it persists.

4. Optional Python reference exercise

Open a small practice folder in VS Code and initialize Git. This fixture is intentionally synthetic: it is a two-column gene/count TSV, not biological evidence and not a normalized single-cell matrix.

mkdir -p omics-copilot-practice/data omics-copilot-practice/scripts omics-copilot-practice/results
cd omics-copilot-practice
git init
echo "# Copilot practice" > README.md
printf 'gene\tcount\nTP53\t12\nBRCA1\t8\n' > data/toy_counts.tsv
git status --short

R first: sort and validate the toy counts

Download the base-R reference script and its focused tests into scripts/. The script requires the exact gene, count header, rejects blank gene names and missing, non-integer, or negative counts, sorts descending, keeps input order for ties, and refuses to overwrite an existing output. It validates the complete input before writing. Read the code first, then use Copilot only as a reviewer or to draft a separate proposal that you compare against the tested reference.

Rscript scripts/sort_counts.R data/toy_counts.tsv results/sorted_counts.tsv
cat results/sorted_counts.tsv
Rscript scripts/test_sort_counts.R scripts/sort_counts.R

For the supplied toy rows, success prints the header followed by TP53 with 12, then BRCA1 with 8. The test script checks the sort, stable ties, wrong headers, malformed and negative counts, input preservation, and the rule that rejected files do not create output. A passing result only checks this small software contract.

Optional Python comparison: if you want to compare languages, ask Copilot for a short Python 3 standard-library script with the same accepted input, sort order, validation, and no-output-on-error contract. A prompt can say: “Write scripts/sort_counts.py to accept input and output paths, require the exact tab-separated header gene and count, reject blank gene names and missing, non-integer, or negative counts, sort descending with stable ties, and never create or replace output on invalid input. Explain each check. This is synthetic data, not biological evidence.” Treat the response as a proposal: inspect the full script and Git diff, test it on copied invalid inputs, and confirm tie behavior before running it.

Run the script from the omics-copilot-practice directory. Use python below, or substitute the working command you used for the version check:

python scripts/sort_counts.py data/toy_counts.tsv results/sorted_counts.tsv
cat results/sorted_counts.tsv

For this fixture, success means the output has the two-column header gene and count, followed by the TSV rows TP53 with count 12 and BRCA1 with count 8, in that order. The script's accepted contract is strict: malformed input should fail with a nonzero status and an explanatory message, and must leave the input unchanged. Before each negative test, remove any prior output so a stale result cannot be mistaken for a fresh one.

1. Check that the code reads the supplied path, preserves both named columns, and does not overwrite its input.
2. Test a missing count with printf 'gene\tcount\nTP53\t\n' > data/bad.tsv, a negative value with printf 'gene\tcount\nTP53\t-1\n' > data/bad.tsv, and a malformed header with printf 'symbol\tcount\nTP53\t12\n' > data/bad.tsv. For each test, run rm -f results/bad.tsv first, then run python scripts/sort_counts.py data/bad.tsv results/bad.tsv. Require a nonzero exit, a useful error, no output file, and an unchanged data/bad.tsv. If any invalid case exits successfully or writes output, stop and revise the code rather than trusting its result.
3. After testing, compare data/toy_counts.tsv with its original two rows and inspect git diff so the source fixture was not overwritten.
4. Record the interpreter version from python --version (or your equivalent) in the README; if you add a dependency, record its version too. Save the prompt, reviewed code, and test inputs if you need to reproduce the exercise later.

Use the same review process on research code

Keep patient identifiers, private datasets, API keys, and credentials out of prompts unless your institution and the service's terms explicitly permit that use. For real analyses, state the matrix orientation, count or normalization status, metadata relationship, package versions, and expected output in the request. Then compare generated code with the relevant package documentation and validate scientific assumptions independently. A plausible plot or successful run is not evidence that the analysis is biologically appropriate.