Git for developers: from init to deploy

Every developer knows the feeling: you have worked on a feature for hours, you save, and then something goes wrong. The production server is running a version you no longer recognize, a colleague has meanwhile made changes that clash with your code, and you have no idea which version is actually "the right one." This is precisely the problem that Git solves—and why every serious developer works with it daily.

Git is the most widely used version control system in the world. It allows you to track changes, collaborate without overwriting each other's work, and deploy to production with confidence. In this article, you walk through the complete Git workflow: from the very first git init to a streamlined deployment. Practical, concrete, and immediately applicable.

The basics: setting up a repository with git init

Everything starts with a repository. A Git repository is simply a folder in which Git tracks all changes. You create one with a single command:

git init mijn-project

This creates a new folder containing a hidden .git folder—the core of your repository. Are you already working in an existing project folder? Then you initialize Git right on the spot:

cd mijn-project
git init

Next, you link a remote repository, for example on GitHub or GitLab:

git remote add origin https://github.com/gebruiker/mijn-project.git

Now your local environment is connected to a central location. This is the basis of every collaboration and every deployment.

Before you make your first commit, it is wise to create a .gitignore file. This file tells Git which files should not be tracked—think of node_modules/, .env files with passwords, or build artifacts. GitHub and GitLab offer ready-made .gitignore templates per language type.

Commits, branches, and the daily workflow

The core of Git revolves around commits. A commit is a snapshot of your code at a specific moment. You add files to the so-called staging area and then save that snapshot:

git add index.php
git commit -m "Voeg contactformulier toe aan homepage"

Do you want to add all changed files at once?

git add .
git commit -m "Initiële projectstructuur"

Always write meaningful commit messages. "Fix bug" says nothing. "Los race condition op in login-handler bij gelijktijdige sessies" says everything. Your future self—and your colleagues—will thank you.

Branching: work in parallel without conflicts

Branches are one of Git's most powerful features. They allow you to work on a feature or bugfix without touching the main branch (main or master). The standard approach:

git checkout -b feature/gebruikerslogin

You are now working on a separate branch. Make commits, test locally, and only then merge back to main. Do you want a structured branching strategy? Then Git Flow is a proven approach:

git flow init

Git Flow introduces fixed branch names for features, releases, and hotfixes. It is somewhat more extensive, but for teams with regular releases, it is an excellent structure. Start a new feature like this:

git flow feature start gebruikerslogin

And finish it with:

git flow feature finish gebruikerslogin

For smaller projects or solo work, a simple main + feature-branches approach is more than sufficient.

Collaborating via pull requests and merge requests

When you are done with a feature, you want that code reviewed before it goes to main. You do this via a pull request (GitHub) or a merge request (GitLab). This is not just a technical step—it is a quality check.

Via the GitHub CLI, you create a pull request directly from your terminal:

gh pr merge

This command merges the pull request linked to your current branch, interactively. You choose yourself whether you want to merge, squash, or rebase. GitLab users do the same with:

glab mr merge

Do you want to create a merge request for review? Then use:

glab mr create

The review process forces you to look at code consciously. Small teams sometimes skip this, but even if you work solo, a pull request is useful: it forces you to reflect on what you have exactly changed before it ends up in production.

Resolving conflicts

Merge conflicts sound scary, but they are normal. They arise when two branches have changed the same lines differently. Git marks the conflicting sections in your file:

<<<<<<< HEAD
echo "Versie A";
=======
echo "Versie B";
>>>>>>> feature/nieuwe-functie

You decide which version wins, or you combine both. Then you add the file and commit:

git add conflict-bestand.php
git commit -m "Los merge-conflict op in uitvoerfunctie"

From commit to deployment: CI/CD with GitHub Actions

A good Git workflow does not end at the merge—that is only the beginning of the deployment. With CI/CD (Continuous Integration / Continuous Deployment), you automate the process of testing and deploying as soon as code lands on main.

GitHub Actions is a popular choice for this. You manage your workflows directly from the CLI:

gh workflow view

This gives you interactive insight into the latest executed jobs per workflow. You immediately see whether a deployment succeeded or where it went wrong.

A simple example of a GitHub Actions workflow for a PHP project:

name: Deploy to production
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Sync to server
        run: rsync -avz ./ user@server:/var/www/html/

Every push to main now automatically triggers a deployment. No more manual FTP-ing, no forgotten files. Your code goes live directly, repeatably, and traceably.

Practical Git tips for daily use

• Commit early, commit often. Small, focused commits are easier to review and revert than large blocks of code.
• Use git stash when you need to switch branches quickly without committing half-finished work: git stash push -m "WIP: login form".
• View your history with git log --oneline --graph for a clear overview of your branches and commits.
• Use tags for releases: git tag -a v1.2.0 -m "Release version 1.2.0" — so you always know which commit corresponds to which production version.
• Never push to main without review — protect your main branch via branch protection rules on GitHub or GitLab.
• Write a good README and document your Git conventions (branch naming, commit style). Newcomers to the team will thank you.

Conclusion: Git is the backbone of your development process

From git init to an automated deployment — Git is the connective tissue of modern software development. It gives you control over your codebase, makes collaboration scalable, and ensures you can deploy with confidence.

The key points at a glance:

• Start every project with git init and a thoughtful .gitignore.
• Work with branches — keep main stable and deployable.
• Use pull requests or merge requests as a quality gate, even when working solo.
• Automate your deployment with CI/CD via GitHub Actions or GitLab Pipelines.
• Write meaningful commit messages — you are documenting your own work.

Git is not a tool you "learn once" and then you're done with it. It is a skill you refine with every project. But with this foundation, you will be immediately more productive, your team will collaborate more smoothly, and you will sleep more peacefully knowing that every deployment is traceable and reversible.