Git Essentials for Developers: Commands, Best Practices, and Real-World Workflow with GitLab

Version control is at the heart of modern software development. Whether you’re working solo or in a distributed team, mastering Git is essential for maintaining code quality, collaboration, and traceability.

In this guide, we’ll cover:

  • Core Git commands every developer must know
  • Best practices for working with repositories
  • A real-world workflow using GitLab
  • How to handle common issues like protected branches
🧱 What is Git?

Git is a distributed version control system that allows developers to:

  • Track changes in code
  • Collaborate across teams
  • Maintain version history
  • Safely experiment with new features
⚙️ Initial Setup (First Time Only)

Before using Git, configure your identity:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Verify:

git config --global --list
📁 Starting a Project with Existing Code

If you already have source code and want to push it to a remote repository:

git init
git add .
git commit -m "Initial commit"
git branch -M main
🔗 Connect to Remote Repository 
git remote add origin https://your-domain/group/project.git

Check:

git remote -v
📤 Push Code to Remote 
git push -u origin main
⚠️ Real-World Scenario: Remote Already Has Code

Sometimes your GitLab project is created with a README or template.

Then you’ll get:

! [rejected] main -> main (fetch first)

Fix:

git pull origin main --allow-unrelated-histories

This merges your local project with the remote.

🔄 Handling Merge Conflicts

If both local and remote contain the same file (e.g., README.md), Git will raise a conflict.

You’ll see:

<<<<<<< HEAD
your content
=======
remote content
>>>>>>> ...

Fix:

  1. Edit the file
  2. Remove conflict markers
  3. Keep desired content

Then:

git add .
git commit -m "Resolve merge conflict"
🔒 Protected Branch Issue (Very Common)

In team environments, the main branch is often protected.

You may see:

You are not allowed to push code to protected branches

This is not an error — it’s a security feature.

✅ Recommended Solution: Use a Feature Branch

Instead of pushing directly to main, create a new branch:

git checkout -b initial-source-upload
git push -u origin initial-source-upload

Then:

  • Go to GitLab
  • Create a Merge Request
  • Merge into main
🧠 Best Practices for Git

1. Never push directly to main

Use feature branches:

feature/login-module
bugfix/payment-error

2. Commit frequently

git commit -m "Add login validation"

Avoid large, unclear commits.

3. Use meaningful commit messages

Bad:

fix stuff

Good:

Fix null pointer exception in payment service

4. Pull before pushing

Always sync with remote:

git pull origin main

5. Use .gitignore

Avoid committing unnecessary files:

node_modules/
.env
*.log
build/
dist/

6. Avoid force push in shared repos

git push --force

Only use this if you fully understand the impact.

🧰 Useful Git Commands (Cheat Sheet)

Check status

git status

Add files

git add .

Commit changes

git commit -m "message"

Push code

git push

Pull latest changes

git pull origin main

Create branch

git checkout -b new-branch

Switch branch

git checkout branch-name

Merge branch

git merge branch-name

View commit history

git log --oneline

Update remote URL

git remote set-url origin https://your-domain/project.git
🧪 Real Workflow Example

Here’s a typical workflow from local code to GitLab:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://your-domain/project.git
git pull origin main --allow-unrelated-histories
git checkout -b initial-source-upload
git push -u origin initial-source-upload

Then:

  • Create merge request
  • Review
  • Merge into main
🚀 Why This Workflow Works
  • Keeps main stable
  • Enables code reviews
  • Prevents accidental overwrites
  • Supports team collaboration
📌 Final Thoughts

Git is more than just a tool — it’s a discipline.

By following best practices:

  • You reduce bugs
  • Improve collaboration
  • Maintain clean project history

And with platforms like GitLab, you can extend this into:

  • CI/CD pipelines
  • Code reviews
  • DevOps automation