Yes — the issue comes from the extra id="..." attributes that got inserted into the code fences. Dev.to expects standard Markdown fences, so those attributes can break rendering.
Here is a clean, copy-paste-ready version in plain Markdown:
# The Simplest Git Workflow for CI/CD When You Need to Deliver Fast
When setting up a CI/CD pipeline, especially in a constrained environment like a fresh VM or a timed setup, it is tempting to use a complex Git workflow with multiple branches.
But in practice, complexity often creates more problems than it solves.
If your goal is to get a working CI/CD pipeline running quickly and reliably, the safest approach is often the simplest one.
This article explains a practical, minimal-risk Git workflow that helps you:
- set up CI/CD quickly
- avoid common mistakes
- focus on delivering a working pipeline
## Why Keep It Simple
Workflows like Git Flow are useful in team environments, but they also add more moving parts:
- pushing to the wrong branch
- pipelines not triggering
- branch-specific jobs not running
- extra time spent debugging Git instead of CI/CD
If your main objective is to get the pipeline working, you want:
- clarity
- predictability
- fewer points of failure
## Recommended Strategy: Single Branch Workflow
### Core Idea
Use one branch only:
```
text
main
Everything happens on that branch.
Why This Works
- Less risk
- Less confusion
- Easier debugging
- Faster setup
- Enough to demonstrate a full CI/CD workflow
Initial Setup
Start by initializing your project and linking it to GitLab:
bash
git init
git branch -M main
git remote add origin http://gitlab.localdomain/your-username/your-project.git
git add .
git commit -m "Initial project import"
git push -u origin main
Daily Workflow
After that, every change follows the same pattern:
bash
git add .
git commit -m "Describe what you changed"
git push
Each push can trigger the pipeline and show your progression in GitLab.
What to Push and When
Instead of pushing everything at once, follow a logical progression.
Step 1 — Push the Raw Project
After extracting and verifying the project, push the initial codebase.
Push:
- application code
- tests
- dependencies such as
requirements.txt
bash
git add .
git commit -m "Initial import of Python project"
git push -u origin main
This gives you a clean baseline in GitLab.
Step 2 — Push Cleanup and Setup
Add basic repository hygiene.
Push:
.gitignore- minor cleanup changes
bash
git add .gitignore
git commit -m "Add gitignore and cleanup"
git push
Step 3 — Push Containerization
Once the application works locally, add Docker support.
Push:
Dockerfile- optionally
docker-compose.yml
bash
git add Dockerfile docker-compose.yml
git commit -m "Add Docker setup"
git push
If you do not need Docker Compose, do not create it just for appearance.
Step 4 — Push SonarQube Configuration
After setting up code quality analysis, push the local configuration file.
Push:
sonar-project.properties
bash
git add sonar-project.properties
git commit -m "Add SonarQube configuration"
git push
Do not push tokens, passwords, or secrets.
Step 5 — Push the CI/CD Pipeline
This is often the most important step.
Push:
.gitlab-ci.yml
bash
git add .gitlab-ci.yml
git commit -m "Add CI/CD pipeline"
git push
This is usually the push that triggers the real automation flow.
Step 6 — Fix and Iterate
If something fails, fix only what is needed and push again.
bash
git add .
git commit -m "Fix pipeline issue"
git push
Then verify the new pipeline run in GitLab.
Full Workflow Step by Step
Here is the full sequence in a clean order.
1. Extract the Project
bash
mkdir -p ~/work
cd ~/work
unzip project.zip -d project
cd project
2. Inspect the Project
bash
ls -la
find . -maxdepth 2 -type f | sort
3. Test Locally First
bash
pip install -r requirements.txt
pytest
python3 app.py
Verify:
bash
curl http://localhost:5000
4. Initialize Git
bash
git init
git branch -M main
git remote add origin http://gitlab.localdomain/your-username/your-project.git
5. Push Initial Code
bash
git add .
git commit -m "Initial project import"
git push -u origin main
6. Add CI/CD Components Step by Step
bash
git add Dockerfile
git commit -m "Add Dockerfile"
git push
bash
git add sonar-project.properties
git commit -m "Add SonarQube config"
git push
bash
git add .gitlab-ci.yml
git commit -m "Add CI/CD pipeline"
git push
7. Fix and Re-Push if Needed
bash
git add .
git commit -m "Fix CI pipeline"
git push
What Not to Push
Never commit sensitive or unnecessary files.
A good .gitignore could look like this:
gitignore
__pycache__/
*.pyc
.pytest_cache/
.venv/
venv/
.env
.sonar/
Avoid pushing:
- credentials
- API keys
- tokens
- local virtual environments
- cache folders
Common Mistakes
Using Multiple Branches Too Early
This often leads to:
- pipelines not triggering
- confusion about where the code is
- jobs running on the wrong branch or not running at all
Pushing to the Wrong Branch
If your pipeline is configured for main only, pushing to another branch may do nothing.
Overengineering Too Early
Trying to set up Git Flow, release branches, and multiple deployment stages before the pipeline even works usually slows everything down.
What If You Still Want Branching
If you want a slightly more structured workflow, keep it limited to:
text
main + develop
Work on develop:
bash
git checkout -b develop
git push -u origin develop
Then merge into main once everything is stable:
bash
git checkout main
git merge develop
git push
Only use this if you are comfortable with branching and know exactly how your pipeline behaves on each branch.
Branch Behavior in GitLab CI
This matters more than many people think.
If your pipeline contains:
yaml
only:
- main
and you are pushing to develop, the job may not run.
If you use two branches, make sure your pipeline allows both:
yaml
only:
- main
- develop
For deployment, it is often better to keep it restricted to one branch only. For example:
yaml
deploy_dev:
stage: deploy
script:
- docker stop python-app-dev || true
- docker rm python-app-dev || true
- docker run -d --network host --name python-app-dev python-app:latest
only:
- main
This is another reason why a single-branch workflow is often safer at the beginning.
Final Recommendation
If your goal is:
- getting CI/CD working
- avoiding unnecessary errors
- delivering quickly
Then the best strategy is usually:
text
Use one branch: main
Push step by step
Keep everything simple
Push in this order:
- imported project
.gitignoreDockerfilesonar-project.properties.gitlab-ci.yml- fixes if needed
Start with:
bash
git init
git branch -M main
git remote add origin http://gitlab.localdomain/your-username/your-project.git
git add .
git commit -m "Initial project import"
git push -u origin main
Then continue with one small, logical push at a time.
Final Thought
CI/CD is not about complex workflows. It is about reliability, repeatability, and control over delivery.
Start simple.
Make it work.
Then improve it.
plaintext
If you want, I can also give you a second cleaned version with a more natural Dev.to style, less academic and more like a real blog post.
Top comments (0)