Veri Analistleri İçin Git ve GitHub

Are Git and GitHub the same thing?

No, and the distinction should be clear from the start. Git is a distributed version control system that tracks changes to your files on your own machine; it works fully without an internet connection. GitHub is a platform that hosts Git repositories online and adds collaboration features such as code review, issues and Pull Requests.

So you can use Git without GitHub; you cannot use GitHub without Git. In practice Git runs locally, and GitHub is the backup and sharing layer.

Core concepts

The most critical concept here is staging, and it is where Git beginners get stuck most. Changing a file does not commit it; git add says "I intend to record this", and git commit records it. That two-step structure looks annoying but is exactly what you need in data projects: it lets you leave the 200 MB CSV sitting in the same folder out and record only the code.

The commands you will use daily

A practical habit: always run git status and git diff --staged before committing. If you are the sort who types git add ., those two commands will save you from an accidentally committed data file.

An example analysis repository

File layout is what lets a visitor work out quickly how to run your project. The structure below is more than enough for small and medium analysis work.

sales-analysis/
├── README.md
├── .gitignore
├── requirements.txt
├── data/
│   └── README.md          # data source and download instructions
├── notebooks/
│   └── 01_monthly_sales.ipynb
├── src/
│   └── analysis.py
└── reports/
    └── .gitkeep

Note that data/ contains a README, not data. If the raw data is not shareable you do not have to put it in the repository — writing down the source, the licence, the download steps and the expected column structure is usually enough. Your code should also state clearly where it expects the data and in what schema.

The .gitkeep inside reports/ is a small trick: Git does not track empty folders, and this empty file preserves the structure.

What should never go into the repository

This is the most important section of the guide for data analysts. Once you push the wrong file, deleting it does not remove it from history — it stays in the older commits.

# raw and private data
data/raw/
data/private/
*.csv
*.xlsx
*.parquet

# secrets
.env
*.pem

# generated files
__pycache__/
.ipynb_checkpoints/
.venv/
reports/*.png

There is a size limit too: GitHub blocks individual files over 100 MiB from a normal Git push and warns above 50 MiB. If you genuinely need large data or model files, look at Git LFS or a separate storage solution.

Step 1: starting the project locally

mkdir sales-analysis
cd sales-analysis

git init -b main
# prepare README.md, .gitignore, the notebook and the code

git status
git add README.md .gitignore requirements.txt notebooks src
git diff --staged          # see what you are about to record
git commit -m "Start the sales analysis project"

A rule that works for commit messages: write them in the imperative, so they complete the sentence "When applied, this commit will ...". "Add a quality check for missing date records" is a good message; "update" or "fix" is not. Six months later, the person reading git log is most likely you.

When should you commit? Not on every small experiment, but when a meaningful, coherent change is finished. A good gauge: if you can write the commit message without the word "and", the scope is probably right.

What a README should contain

• The analysis question and a one-paragraph summary of the project
• Data source, licence and access instructions (say so explicitly if it is not shared)
• Python version and the installation command
• Steps to run the analysis from start to finish
• Definitions of key metrics and the assumptions made
• An example output or chart
• Scope, limitations and contact details

Step 2: pushing to GitHub

1. Create a repository on GitHub with New repository; set the name and visibility (public/private).
2. Since you are pushing an existing local project, do not let GitHub create an initial commit with a README, .gitignore or licence. Otherwise you end up with two separate histories and an unnecessary conflict on the first push.
3. Copy the repository's HTTPS or SSH address.
4. Define the remote locally and push the main branch.

git remote add origin https://github.com/USERNAME/sales-analysis.git
git remote -v
git push -u origin main

The -u flag links your local main to the remote one, so later a plain git push is enough. For authentication, do not type your password on the command line — use an SSH key, a personal access token or a credential manager.

Branch, merge and Pull Request

Even working alone, branches earn their keep: the main branch always holds a working version. If a new analysis attempt goes nowhere, you delete the branch and main is untouched.

git switch -c feature/monthly-trend

# add the monthly trend chart in the notebook or code
git status
git add notebooks/01_monthly_sales.ipynb
git commit -m "Add the monthly sales trend chart"
git push -u origin feature/monthly-trend

On GitHub you then open a Pull Request from that branch. A PR is a place to review the change, add explanation and discuss it. Opening one on your own project is still useful: seeing the full diff in one place catches things you missed while committing.

git switch main
git pull origin main
git merge feature/monthly-trend
git push origin main

If two branches changed the same lines differently, you get a merge conflict. Git marks the conflicting regions in the file; you decide which version survives, remove the markers, stage the file and complete the merge. In analysis projects, run the code once after resolving a conflict — the syntax can look fine while the logic is broken.

Notebooks and Git: a special problem

An .ipynb file is JSON, and cell outputs live inside it. That has two consequences. First, running a single cell can produce a diff of hundreds of lines, making git diff unreadable. Second, because charts are embedded as base64, the repository grows fast.

Practical fixes:

Practical notes for analysts

• Reproducibility: run the notebook top to bottom and confirm it produces a clean result; pin package versions with requirements.txt or a lock file.
• Sample data: if you want the project to be runnable, include a small synthetic or openly licensed sample. Not the real data.
• Metric definitions: put chart units, the date filter and metric formulas in the README. The code will not tell anyone those.
• Beware forceful commands: git push --force and history-rewriting commands can erase other people's work on a shared branch.
• Undoing: use git revert to undo a bad commit; it creates a new commit and leaves history intact.

Checklist before pushing

• Do the repository name and README explain what the project does?
• Is there any sensitive data, key, password or private file in there?
• Does .gitignore cover the data folder, the virtual environment and temporary output?
• Does the notebook run cleanly from the top, and were outputs cleared?
• Are packages and versions stated?
• Are charts labelled and metric assumptions written down?
• Were git status and the staged diff reviewed?
• Is the commit message clear and the remote correct?

Conclusion

Learning Git is less about memorising commands than about building a habit: keep the change small, write down what you did, look before you push. In data analysis the payoff is unusually concrete — the answer to "why was this figure different last month?" sits in your commit history.

Do not wait for a big project to start. Pick a small open-data analysis, write the .gitignore first, make five or ten commits, and fill in the README as if someone else will read it. That little repository both builds the habit and becomes the first real piece of work you can show.