Creating and Configuring a Public GitHub Repository

Hello! This course will build a public portfolio in stages: first a small, complete company research case, then valuation and transaction work, and later broader sector, PE, and VC studies. Today’s task is narrower. You will create the single GitHub repository that can eventually hold those studies, while making sure it is safe to publish.

You already have experience with GitHub, so there is no need for a full Git tutorial. The important distinction here is between having a public repository and having a resume-ready case: today establishes the former. A recruiter-facing link becomes useful once the first finished, sourced case is inside it. Allow about 35–40 minutes, including the setup.

Decide what the repository promises

A recruiter should be able to understand the repository from its name and one-line description without opening a file. Use a broad name so that a later M&A case does not make an earlier company research study look out of place.

A workable starting choice is:

• Name: company-research-and-deal-cases
• Description: Evidence-led company and sector research, valuation models, and transaction case studies.

You can choose your own wording. Keep it descriptive rather than claiming that the repository already contains completed models or investment recommendations. You do not need to choose a company today; that decision belongs to the research stage.

Before creating anything, watch the repository-creation portion of this demonstration. Its presenter suggests a private practice repository for someone learning GitHub; your choice will be public because this is intended to become a portfolio.

Create the public repository

GitHub’s creation guide is the reference for the current workflow. Read the part of its numbered procedure covering the owner, name, visibility, and optional starting files before opening the form.

Now make the repository in your browser:

1. While signed in to GitHub, select New repository from the creation menu. Choose the account that should own your portfolio.
2. Enter your name and description. Set visibility to Public. This means anyone with the link can view the repository and its published history.
3. Select Add a README. The README will become the landing-page explanation; you will give it a modest, accurate introduction shortly.
4. For Add .gitignore, select Python if offered. It is a useful starting point for the small financial tools you plan to add later. An ignore file specifies files Git should leave untracked; it is not a security system.
5. For Choose a license, select MIT License if you are comfortable allowing others to reuse your original work under its terms. MIT permits broad reuse, including commercial reuse, subject to its notice requirements. It does not give you permission to republish someone else’s report, dataset, chart, or annual-report PDF. If you do not want to grant those permissions for your own work, pause and choose a license you understand rather than selecting MIT just to fill a field.
6. Select Create repository.

For this course, the straightforward MIT choice covers work you create and have the right to license. Keep third-party materials as citations and links unless you have permission to redistribute them. Before publishing a future model or report, check that its inputs, quotations, images, and embedded files respect that boundary.

Make the landing page honest and useful

Open README.md on the new repository page and use GitHub’s edit control to replace any near-empty starter text. A short version is enough today:

# Company Research and Deal Cases

A portfolio in progress covering company and sector research, valuation,
and transaction analysis.

Each published case will link its principal sources and distinguish
reported facts from assumptions, calculations, and conclusions.

Completed cases will be indexed here as they are published.

Commit that edit using the browser’s Commit changes control. This is deliberately a statement of scope, not a claim that any case is finished. Later lessons will turn this landing page into an index with direct links to reports, models, and presentations.

After saving, check the repository’s About area. It should display a useful description, while the page below should display your README. In the example screenshot, the highlighted labels are topics—optional discovery tags, not substitutes for a clear description or README.

Configure publication safeguards

A public portfolio may eventually contain Python notebooks, spreadsheets, downloaded data, and exported reports. Two risks deserve attention from the start: inadvertently committing a credential, and publishing material you have no right to distribute. GitHub can help detect some technical risks, but you remain responsible for reviewing every file.

Read GitHub’s guidance before checking the settings:

In your repository, open Settings, then Advanced Security under Security and quality (use the menu if Settings is not visible). Check secret scanning and push protection and enable them where the controls are available. Enable Dependabot alerts where offered; they become particularly relevant when the repository has software dependencies. If code scanning requires additional setup, note it for when you publish code rather than mistaking an unfinished setup for active protection. GitHub’s labels and available controls can vary with account and repository settings.

Also open .gitignore and inspect it. Before you ever work with API keys, ensure local environment files are excluded; you can append these common rules if they are not already covered:

.env
.env.*
!.env.example
*.pem

The exception allows a future .env.example containing placeholder names only, never real values. Do not add blanket rules that hide every spreadsheet or PDF: finished models and reports may be the very files you intend to publish.

An ignore rule does not protect a file that was already committed, and scanning may miss a secret. Before each future upload, inspect the files being committed. If a credential is ever exposed, revoke or rotate it promptly; deleting the visible file alone does not remove it from Git history. Likewise, review spreadsheet tabs and document metadata, local file paths, private work material, and any third-party content before publication.

Confirm the result

Open the repository in a browser session where you are not signed in. A visitor should be able to see:

• a public repository with a clear name and accurate About description;
• a README that explains its scope without pretending cases are complete;
• a visible LICENSE file reflecting a permission choice you understand;
• a .gitignore file, plus the security features you could enable in Settings.

If those checks pass, you have completed today’s outcome. Keep the link, but do not describe the repository on your resume as a finished research portfolio yet. The first complete case—not the empty container—will support that claim.

Takeaway

You now have a public home for the portfolio, a clear statement of what it will contain, an explicit reuse license, and initial publication safeguards. The most important habit is to treat public as a review decision for every future commit, not just a visibility switch selected once.

Next, you will define who the first project is for, what it must deliver, and what “complete enough to show in an interview” means.