Switching to Git: Leaving FTP File Uploads Behind

I’ve been writing code for six years, and for most of that time I deployed by uploading files over FTP. Make a change, open FileZilla, push the modified file to the server. When something broke, I’d burn mental energy trying to remember what the previous version looked like. Occasionally I’d drive myself crazy wondering, “what exactly did this look like before I changed it?”

This month I decided to properly learn Git. I’d been saying “I should use it” for years — but this project finally made it non-negotiable.

What is Git?

Version control is a system that lets you track changes to your files over time. Git is currently the most widely used distributed version control system.

The practical benefit: every change is recorded, you can return to any point in history, you can open separate branches for different features, and you can see exactly when and why something was changed.

Basic setup

After installing Git, you configure your identity:

git config --global user.name "Muhammet Şafak"
git config --global user.email "[email protected]"

To initialize a project as a Git repository, run this inside the project folder:

git init

This creates a hidden .git/ directory. Your project is now a Git repository.

Your first commit

Saving changes happens in two steps: first you choose which files to include (staging), then you record them (commit).

# Stage a single file
git add src/Models/User.php

# Stage all changes
git add .

# Create the commit
git commit -m "Kullanıcı modeli eklendi"

A commit message should explain what was done when you look back at the history later. Vague messages like “updated” or “fixed” become useless over time.

I underestimated this at first. My commit messages during the first week were genuinely worthless: “change”, “fix”, “again”. Two weeks later I looked at the log and not a single line told me what had happened or when. Since that day I’ve tried to write every message as an answer to the question: “what did I do, and why?”

Creating branches

Working directly on the main branch while developing a new feature is risky. If something breaks, everything breaks. That’s what branches are for:

# Create a new branch and switch to it
git checkout -b yorum-ozelligi

# Switch between branches
git checkout main

You can work freely on the yorum-ozelligi branch without touching the main branch. When you’re done, you merge it back:

git checkout main
git merge yorum-ozelligi

Once this workflow clicked for me, I realised just how blind FTP-based deployment really was.

On a current project, a client asked me to change something mid-flight while I was already developing another feature. I switched to a branch, made the change, merged it, and carried on. In the FTP era I would have had to either track the changes mentally or save individual files under different names as backups. Both are terrible solutions.

Checking status and history

# See what has changed
git status

# See detailed diffs
git diff

# Compact commit history
git log --oneline

The output of git log --oneline looks like this:

a3f2c1b Yorum formu doğrulaması eklendi
9d1e4a0 Kullanıcı profil sayfası düzenlendi
7b2f3c1 Veritabanı bağlantısı yapılandırıldı

Each line shows a commit hash and message. This list is enough to see what changed and when.

Rolling back a mistake

This is Git’s most reassuring feature. To revert to a previous commit:

# Undo the last commit (changes are not lost — they go back to staging)
git reset HEAD~1

# Restore a specific file from a specific commit
git checkout 9d1e4a0 -- src/Models/User.php

Back in the FTP days, accidentally overwriting a file meant the change was gone for good. Now I can look through the Git history and restore any point I want.

The first time this really hit home: while testing a payment integration I spotted a logic error but had no idea where it came from. I ran git diff to see exactly what I had changed in the last two hours, and found the bug in three minutes. If I had been working with FTP, I might not have even remembered which files I’d touched.

Remote repositories with GitHub

Instead of keeping the project local only, pushing to a remote repository gives you both a backup and accessibility from anywhere. GitHub is the most common platform for this:

# Add a remote
git remote add origin https://github.com/kullanici/proje.git

# Push changes
git push -u origin main

Now I can clone the project on any other machine and pick up right where I left off.

The difference from FTP

With FTP, the file on the server was the single source of truth; the local working copy was just a transient intermediate state. If you made a mess, you only found out after pushing it to the server.

With Git, everything is recorded in the local history. Before pushing to the server you can review the change, test it, and roll it back if needed. That sense of confidence changes the way you work — you experiment more freely.

The biggest psychological difference between FTP and Git, in practice, is this: every move in FTP felt irreversible, so I experimented less. With Git, the default mindset is “I’ll try it; if it doesn’t work I’ll undo it.” That courage unexpectedly leads to better code as well.

All my active projects are now on Git. A long overdue step — but it’s done.