Webbo3 Data Analysis Bootcamp · Version Control Module · Lesson 1

GitHub and Collaboration: Repositories, Branches, Pull Requests, and Professional README Files

A hands-on lesson covering how to create repositories on GitHub, synchronize code with push and pull, work with branches, submit pull requests, resolve merge conflicts, and write README files that make your projects credible.

Writing code or building a data analysis workbook is only half the job. The other half is managing that work so other people can use it, review it, and improve it without breaking what already works. If you have ever emailed a file named final_report_v3_ACTUAL_FINAL.xlsx to a teammate, you already understand why version control exists. Git is the industry standard for tracking changes to files over time. GitHub is the platform that hosts those tracked files on the internet and adds collaboration tools like pull requests, issue tracking, and code review. Together they form the backbone of every professional software and data team. This lesson teaches you to create a repository, move code between your computer and GitHub, branch safely, merge cleanly, and present your work with a professional README. These are not optional skills. They are prerequisites for any job that involves writing code or sharing analysis.

1. Creating a Repository on GitHub

A repository, or repo, is a container for your project. It holds your files, the entire history of every change you have made to those files, and metadata like who made each change and when. Creating a repo is the first step of every project you will ever share.

Creating a GitHub account. Go to github.com and sign up with your email address. Choose a professional username. Recruiters and hiring managers will see this. A username like adeola-data or chidinma-analytics is appropriate. Avoid handles with random numbers, slang, or anything you would not put on a resume. Verify your email address before proceeding.

Creating a new repository. Click the plus icon in the top-right corner of GitHub and select New repository. You will see a form with several fields. The repository name should be short, descriptive, and lowercase with hyphens. For a data analysis project on Nigerian retail sales, a good name is nigerian-retail-analysis. A bad name is project1 or my-stuff. Add a description in one sentence: "Data cleaning, analysis, and dashboard for Nigerian retail sales Q1 2026." Choose whether the repo is public, visible to everyone, or private, visible only to you and people you invite. For a bootcamp portfolio, public is better because it becomes part of your professional profile. Check the box to Add a README file. This creates an initial commit so your repo is not empty. Check the box to Add .gitignore and choose a template. For data projects, the Python template is a good starting point because it ignores cache files and virtual environment folders. Choose a license if you want, MIT is the standard for open-source educational work. Click Create repository.

Understanding what just happened. GitHub created a remote repository on its servers. Remote means it lives on the internet, not on your computer. The README file is already there. The .gitignore file tells Git which files to ignore, so they are not tracked or uploaded. Common ignored files include Excel temporary files, Python cache folders, and large datasets that should not be stored in version control. Your local machine does not have this repository yet. You will bring it down in the next section.

The repository page. After creation, you land on the main page of your repo. The top navigation shows Code, Issues, Pull requests, Actions, and Settings. The center panel displays your README content. The right sidebar shows metadata like license, language, and last update time. This page is your project's public face. Every file you add, every change you push, and every discussion you have will be visible here.

2. git clone, git push, and git pull

Git is a command-line tool that tracks changes to files on your local machine. GitHub is the remote server where those tracked files are stored and shared. The commands that move data between your machine and GitHub are clone, push, and pull. These three commands form the daily rhythm of every developer and analyst who uses Git.

git clone: downloading a repository. When a repository exists on GitHub but not on your computer, you clone it. Cloning creates a complete local copy, including every file and the entire history of changes. Open your terminal or Git Bash. Navigate to the folder where you want the project to live, for example your Documents folder. On GitHub, click the green Code button on your repository page and copy the HTTPS URL, which looks like https://github.com/yourusername/nigerian-retail-analysis.git. Then run:

git clone https://github.com/yourusername/nigerian-retail-analysis.git

Git creates a new folder named nigerian-retail-analysis inside your current directory. Inside that folder you will see your README.md file and your .gitignore file. You will also see a hidden .git folder. This folder contains the entire history of the repository. Do not touch it, delete it, or modify it manually. If you delete the .git folder, your local copy becomes a plain folder with no version control.

Making changes and tracking them. After cloning, you work inside the repository folder just like any other folder. Add your Excel workbook, your SQL scripts, or your Python notebooks. When you are ready to save your progress to Git's history, you use a three-step workflow. First, stage the files you want to track:

git add README.md
git add analysis-workbook.xlsx

Staging tells Git which changes you want to include in the next snapshot. You can stage individual files or all changed files at once with git add .. Second, commit the staged changes with a message:

git commit -m "Add initial data cleaning and summary analysis"

A commit is a snapshot of your project at a specific moment. The message should describe what changed and why, not just what file was added. Bad messages are "update" or "fix." Good messages are "Standardize region names and remove duplicate transactions" or "Add Q1 revenue Pivot Table to Analysis sheet." Write your commit messages in the imperative mood, as if you are giving a command: "Add feature," not "Added feature." This is the convention used by the Git project itself and most professional teams.

git push: uploading to GitHub. Committing saves changes locally. Pushing uploads those commits to the remote repository on GitHub:

git push origin main

Origin is the default nickname for your remote repository on GitHub. Main is the default name of your primary branch. After pushing, refresh your repository page on GitHub. You will see your new files, your commit message, and a timestamp. If you are pushing for the first time from a new machine, GitHub may ask for authentication. Use a personal access token instead of your password. Go to GitHub Settings, Developer settings, Personal access tokens, and generate a token with repo scope. Copy the token and paste it when prompted. Store it securely, because GitHub shows it only once.

git pull: downloading updates. When a teammate pushes changes to the remote repository, your local copy becomes outdated. To bring those changes down to your machine, run:

git pull origin main

This fetches the latest commits from GitHub and merges them into your local branch. You should pull before you start working every day, and before you push, to minimize the chance of conflicts. The professional workflow is: pull, work, commit, pull again to check for new changes, then push. If you push without pulling first and someone else has pushed in the meantime, GitHub will reject your push and tell you to pull and resolve any conflicts first.

3. Branches: git branch, git checkout, and git merge

The main branch is your production-ready code. You do not experiment on it. You do not fix bugs directly on it. You do not add new features to it without review. Branches let you create isolated copies of your project where you can work safely without affecting the main branch. When your work is complete and tested, you merge it back into main. This is how professional teams prevent the chaos of everyone editing the same files simultaneously.

Understanding branches. Think of a branch as a parallel timeline. The main branch is the official timeline. When you create a new branch, you spawn a separate timeline that starts from the current state of main but diverges as you make changes. Changes on your branch do not appear on main until you explicitly merge them. Other people can continue working on main while you work on your branch. When you are ready, you merge your timeline back into the official one.

git branch: seeing and creating branches. To see all branches in your repository, run:

git branch

This lists your local branches. The branch you are currently on is marked with an asterisk. To create a new branch without switching to it:

git branch feature-dashboard-interactivity

Branch names should be descriptive and lowercase with hyphens. Common prefixes are feature- for new functionality, bugfix- for corrections, and hotfix- for urgent production repairs. For a data project, you might use feature-add-pivot-tables, bugfix-correct-revenue-formula, or experiment-test-new-chart-types.

git checkout: switching branches. Creating a branch does not move you onto it. To switch to your new branch:

git checkout feature-dashboard-interactivity

Now your commits will be saved to this branch instead of main. You can verify which branch you are on by running git branch again. The asterisk will have moved. A shortcut to create and switch in one command is:

git checkout -b feature-dashboard-interactivity

The -b flag means create the branch and switch to it immediately. This is the command you will use most often.

Working on a branch. Once on your feature branch, work normally. Edit files, stage them with git add, commit with git commit -m, and push with git push origin feature-dashboard-interactivity. Notice that the push command specifies your branch name, not main. This uploads your branch to GitHub without touching the main branch. On GitHub, you can now see two branches listed in the branch dropdown at the top-left of your repository page.

git merge: bringing branches together. When your feature is complete and tested, you merge it into main. First, switch back to main:

git checkout main
git pull origin main

Pulling ensures your local main is up to date with any changes teammates pushed while you were working. Then merge your feature branch:

git merge feature-dashboard-interactivity

If no one else edited the same files you edited, Git performs a fast-forward merge, which simply moves the main branch pointer to your feature branch's latest commit. If main has new commits that your branch does not have, Git performs a three-way merge, creating a new merge commit that combines both timelines. After merging, push main to GitHub:

git push origin main

Once merged and pushed, your feature is now part of the official project. You can delete the feature branch locally with git branch -d feature-dashboard-interactivity and remotely on GitHub through the branches page. Deleting old branches keeps your repository clean and prevents confusion about which branches are still active.

4. Pull Requests

Merging branches locally with git merge works, but it skips the most important step in professional collaboration: review. A pull request, or PR, is a formal proposal to merge one branch into another. It opens a discussion thread where teammates can review your changes, leave comments, request modifications, and approve or reject the merge. Pull requests are the gate that keeps broken code out of main.

Creating a pull request on GitHub. After pushing your feature branch to GitHub, go to your repository page. GitHub usually displays a yellow banner suggesting you create a pull request for your recently pushed branch. Click Compare and pull request. If the banner does not appear, go to the Pull requests tab and click New pull request. Select your feature branch as the compare branch and main as the base branch. GitHub shows a diff, a line-by-line comparison of what changed. Review this carefully before submitting.

Writing a good pull request description. The title should summarize the change in one line: "Add interactive region filter to sales dashboard." The description should explain what changed, why it was necessary, and how to test it. For example: "This pull request adds a Combo Box form control to the dashboard sheet, linked to a dynamic Pivot Table on the Analysis sheet. Users can now filter the revenue chart by region. To test, open the Dashboard sheet, select a region from the dropdown, and confirm the chart updates. The Analysis sheet formulas have been verified against manual calculations for Lagos and Abuja." A good description reduces back-and-forth and helps reviewers verify your work quickly.

The review process. After creating the pull request, assign reviewers. In a bootcamp setting, this is your instructor or a peer. Reviewers examine the diff, leave comments on specific lines, and either approve the PR or request changes. If changes are requested, you make the edits on your local feature branch, commit them, push them, and the pull request updates automatically. No need to create a new PR. Once approved, you or a designated maintainer clicks Merge pull request. GitHub offers three merge strategies. Create a merge commit preserves the full branch history. Squash and merge combines all your branch commits into one clean commit on main, which keeps the main history tidy. Rebase and merge replays your commits on top of main without a merge commit, creating a linear history. For bootcamp projects, squash and merge is usually the cleanest option.

Why pull requests matter even for solo projects. Even if you are working alone, creating a pull request for your own merges forces you to review your own diff before merging. You will catch mistakes, leftover debug code, and files you accidentally staged. It also builds the habit of documenting changes, which pays off enormously when you return to a project after six months and cannot remember why you made a particular edit.

5. Resolving Merge Conflicts

A merge conflict occurs when two branches have edited the same part of the same file in different ways, and Git cannot decide which version is correct. Conflicts are not failures. They are a natural consequence of parallel work. Knowing how to resolve them calmly is a mark of professional maturity.

How conflicts happen. Imagine you and a teammate both clone main. You edit line 15 of analysis.sql to add a new filter. Your teammate edits the same line 15 to add a different filter. Your teammate pushes first. When you pull and try to merge, Git sees two different versions of line 15 and raises a conflict. It does not guess which one is right because guessing would risk data loss.

Recognizing a conflict. When Git encounters a conflict, it pauses the merge and marks the conflicting file. If you run git status, you see the file listed as Unmerged. If you open the file in a text editor, you see conflict markers that look like this:

<<<<<<< HEAD
WHERE region = 'Lagos'
=======
WHERE region = 'Abuja'
>>>>>> feature-add-abuja-filter

The section between <<<<<<< HEAD and ======= is your version, from the branch you are currently on. The section between ======= and >>>>>>> feature-add-abuja-filter is your teammate's version, from the branch you are trying to merge. Your job is to edit the file so it contains the correct final version, removing all the markers.

Resolving manually. Open the file in your code editor. Read both versions. Decide what the final code should be. In this example, maybe the correct answer is to support both regions using IN:

WHERE region IN ('Lagos', 'Abuja')

Delete the conflict markers and the rejected lines. Save the file. Then stage it and complete the merge:

git add analysis.sql
git commit -m "Resolve merge conflict: support both Lagos and Abuja filters"

Using a merge tool. For complex conflicts involving multiple files, a visual merge tool makes resolution easier. Popular options include VS Code's built-in merge editor, which shows both versions side by side with a center panel for the resolved result. To configure VS Code as your merge tool, run git config --global merge.tool vscode and git config --global mergetool.vscode.cmd "code --wait $MERGED". Then when a conflict occurs, run git mergetool to open the visual editor.

Aborting a merge. If the conflict is too complex to resolve immediately, or if you realize you pulled the wrong branch, you can abort the merge and return to your pre-merge state:

git merge --abort

This is safe. It reverts all changes made by the merge attempt and leaves your branch exactly as it was. Abort, regroup, and try again when you have a clearer understanding of what both branches changed.

6. README Files

Your README.md file is the first thing anyone sees when they visit your repository. It is your project's elevator pitch. A good README explains what the project does, why it exists, how to use it, and who built it. A missing or poorly written README makes a project look abandoned or amateur, no matter how good the code inside is.

What is Markdown. README files use Markdown, a lightweight markup language. A .md extension means Markdown. Hash symbols create headings: # for H1, ## for H2, ### for H3. Asterisks create emphasis: *italic* or **bold**. Backticks create inline code: `SELECT * FROM customers`. Triple backticks create code blocks. Hyphens create bullet lists. Numbers create ordered lists. Links use square brackets and parentheses: [Google](https://google.com). Images use an exclamation mark before the same syntax. Markdown is simple to learn and readable even as plain text, which is why it has become the standard for documentation.

The essential sections of a professional README. Every README should include at least these sections. Project title and one-line description at the top. A brief overview paragraph explaining the problem the project solves. A table of contents for longer READMEs. Installation instructions, step by step, including prerequisites like software versions. Usage instructions with examples. For data projects, include a data dictionary explaining what each column means and where the data came from. A section on methodology, what tools you used and why. A results section with key findings or screenshots. A credits or author section. A license statement if the project is open source.

A data project README example. Here is a structure for the Nigerian retail analysis project:

# Nigerian Retail Sales Analysis

## Overview
This project analyzes 2,500 retail transactions from NovaMart stores across six regions in Nigeria. The goal is to identify top-performing product categories, regional sales trends, and underperforming stores.

## Tools Used
- Microsoft Excel for data cleaning, Pivot Tables, and dashboard design
- MySQL for structured data storage and query validation
- Git and GitHub for version control

## Data Dictionary
| Column | Description | Data Type |
|--------|-------------|-----------|
| transaction_id | Unique identifier | INT |
| date | Transaction date | DATE |
| store | Store name | VARCHAR |
| region | Geographic region | VARCHAR |
| product_category | Electronics, Clothing, Home Goods, Groceries | VARCHAR |
| quantity | Units sold | INT |
| unit_price | Price per unit in NGN | DECIMAL |
| discount | Discount percentage | DECIMAL |

## Methodology
1. Data cleaning: removed duplicates, standardized text, corrected dates
2. Analysis: built Pivot Tables for revenue by category and region
3. Visualization: created four charts and an interactive dashboard
4. Protection: locked formulas and hid analysis sheets

## Key Findings
- Electronics generates 42% of total revenue
- Lagos region outperforms the company average by 18%
- The Ikeja store is the bottom performer by net revenue

## How to Use
1. Clone this repository
2. Open `Capstone_Adeola.xlsx` in Excel 365 or later
3. Navigate to the Dashboard sheet
4. Use the region dropdown to filter the view

## Author
Adeola Ogunleye, Data Analysis Bootcamp, Webbo3, 2026.

Why the data dictionary matters. In data projects, your audience includes other analysts who need to understand your columns without opening the raw file. A data dictionary in a table format, using Markdown pipe syntax, is the professional standard. It shows that you understand your data at the semantic level, not just the mechanical level.

Keeping the README updated. A README that describes features you removed three weeks ago is worse than no README at all. Every time you make a significant change to the project, update the README in the same commit. If you add a new chart, add a screenshot to the README. If you change the installation steps, update the instructions immediately. An outdated README signals poor project hygiene to anyone reviewing your work, including potential employers.

Using AI to Move Faster in Version Control and Collaboration

Git commands are not difficult to memorize, but the workflow around them, when to branch, how to write commit messages, what to put in a README, benefits enormously from AI assistance. Here is how to apply it without outsourcing your judgment.

1. Use AI to generate .gitignore files for data projects.
A .gitignore for a data project needs to exclude Excel temporary files, large CSV datasets, and Python cache folders. Instead of writing one from scratch, ask Copilot: "Generate a .gitignore file for a data analysis project that uses Excel, Python, and MySQL. Exclude temporary files, datasets over 10MB, and credential files." AI will produce a comprehensive list including *.xlsx~, __pycache__/, and .env. Review it to make sure it does not ignore files you actually want to track, like your final dashboard workbook, then commit it.

2. Draft commit messages with AI, then edit them.
If you have made many changes and struggle to summarize them in one line, describe your changes to AI: "I cleaned the region column, removed 47 duplicate rows, standardized date formats, and added a revenue calculation column. Write a concise Git commit message in imperative mood." AI might suggest "Clean region data, remove duplicates, and add revenue column." Use this as a starting point, but ensure it reflects your actual changes and follows your team's conventions.

3. Use AI to explain merge conflicts in plain English.
When you encounter a conflict, paste the conflict markers into an AI assistant and ask: "Explain what both versions of this code are trying to do, and suggest a resolution that preserves both intentions." AI will parse the two versions, explain the difference, and propose a merged version. You still need to verify the suggestion against your understanding of the project, but AI removes the intimidation factor of staring at angle brackets and equal signs.

4. Generate README drafts from your project structure.
After completing a project, list your files and ask AI: "Write a professional README for a data analysis project with these files: cleaned_data.csv, analysis.sql, dashboard.xlsx, and charts folder. Include a data dictionary, methodology, and usage instructions." AI will generate a solid structure. Your job is to fill in the actual insights, correct the column descriptions, and add screenshots. This turns README writing from a blank-page problem into an editing task.

5. Verify AI-generated Git commands before executing them.
AI can suggest destructive commands like git reset --hard or git push --force without warning you about the consequences. Never run a command you do not fully understand, especially if it contains --force, --hard, or delete. When in doubt, ask AI to explain what the command does and whether there is a safer alternative. In Git, almost every destructive action has a safer equivalent. Prefer git revert over git reset, prefer git merge --abort over manual conflict hacking, and never force push to main on a shared repository.

A habit worth building from this lesson onward: before every push, run git status and git diff to review exactly what you are about to upload. Before every merge, read the pull request description and the diff to confirm you understand what is changing. Git is a safety net, but only if you look before you leap. AI can help you read faster and write cleaner, but the final decision to commit, push, and merge is always yours.

Next lesson: Python fundamentals for data analysis: variables, data types, and control flow.