Setting Up a Git Repository for 1C-Bitrix: Workflow, CI, .gitignore

Imagine this: you're updating an online store's catalog with 50,000 products via FTP. You make changes to a template, upload it—and get a 500 error because a colleague was editing the same file simultaneously. Sound familiar? We had a client like that: every other release broke functionality, recovery took 3 hours. Switching to Git solved it—recovery time dropped to 15 minutes, incidents decreased 5 times. Proper Git repository setup for 1C-Bitrix is not just "committing a folder" but building a workflow that eliminates human error and accelerates releases by 3x. Our engineers with 10+ years of experience have completed over 50 migrations to Git for projects of varying complexity.

Why can't you just add /bitrix/ to the repository?

The Bitrix core is hundreds of megabytes of binary files and frequent updates. If you dump it into Git, every push will pull gigabytes, and the commit history will drown in changes to standard modules. Our goal is to store only what the team creates. Ignoring /bitrix/ and /upload/ is the first rule. Compare: Git deployment is 5 times faster than FTP upload, and rollback takes minutes instead of hours.

What to store in Git and what to exclude?

How to configure .gitignore – a proven template?

# Bitrix core /bitrix/ # User content /upload/ # Configuration with secrets /.env /bitrix/php_interface/dbconn.php # Cache /bitrix/cache/ /bitrix/managed_cache/ /bitrix/stack_cache/ # IDE /.idea/ /.vscode/ *.swp # Node.js (if used in local/) /local/node_modules/ /local/.npm/ # OS .DS_Store Thumbs.db 

This template will save you hours of debugging. Add it before the first git add. Optionally, you can exclude /local/vendor/ if using Composer and /bitrix/tmp/.

Initializing an existing project: step by step

If the project is already on the server, proceed as follows:

cd /var/www/myshop git init git remote add origin [email protected]:projects/myshop.git nano .gitignore # paste the content above git add local/ .gitignore deploy/ nginx.conf.example .env.example git commit -m "Initial commit: local customizations" git push -u origin main 

If you accidentally added /bitrix/ to the index, remove it:

git rm -r --cached bitrix/ upload/ git commit -m "Remove bitrix/ and upload/ from tracking" 

How to organize branches and workflow?

For Bitrix projects, we recommend a simplified GitFlow. Compare with FTP deployment: Git reduces recovery time after a failure by 3x and eliminates human error. Automation with Git cuts deployment time from 2 hours to 10 minutes.

main – production (only via CI) develop – main branch (auto-deploy to staging) feature/* – tasks (feature/JIRA-123-new-filter) hotfix/* – urgent production fixes 

Write commits following Conventional Commits: feat(catalog): add ajax filter, fix(checkout): null reference, refactor(helpers): move functions.

How to set up CI/CD for a Bitrix project?

After setting up the repository, we connect CI. For example, GitLab CI: on every push to develop, a build, test, and deploy to staging runs. On main — deploy to production after verification. This saves up to 40% of debugging time and eliminates manual deployment errors. Example of a simple .gitlab-ci.yml:

stages: - deploy deploy_staging: stage: deploy script: - rsync -avz --exclude-from='.gitignore' . user@staging:/var/www/ only: - develop 

What to do about merge conflicts?

Conflicts occur when two developers modify the same file. Solution: before merging, frequently do git pull --rebase and communicate with the team. If a conflict occurs, resolve it manually by removing the markers <<<<<<<, =======, >>>>>>>. For Bitrix, typical conflicts are in dbconn.php (but it's not in the repository) and in templates. Our experience: with proper workflow, conflicts occur no more than once a month, and resolution takes 10–15 minutes.

How to work with configuration files?

Secrets go only in .env. The dbconn.php file is not committed; on the server it is created by the deployment script. Example content:

<?php $DBHost = getenv('DB_HOST') ?: 'localhost'; $DBLogin = getenv('DB_USER') ?: 'bitrix'; $DBPassword = getenv('DB_PASSWORD') ?: ''; $DBName = getenv('DB_NAME') ?: 'bitrix_db'; ?> 

And .env.example is committed with empty keys:

DB_HOST= DB_USER= DB_PASSWORD= DB_NAME= SMTP_HOST= 

What you get as a result

We set up a Git repository turnkey:

• correct .gitignore tailored to your Bitrix version;
• initialization and first commit with the right files;
• branch setup, merge rules, and CI (GitLab CI / GitHub Actions);
• workflow documentation for the team;
• training developers on Git basics for Bitrix.

After Git setup, you cut debugging costs by 40% — the team spends time on features, not resolving conflicts. Contact us — we'll evaluate your project within one business day. Our engineers have over 10 years of experience and have completed 50+ successful Git migrations. We are certified 1C-Bitrix specialists.

Git — distributed version control system (wikipedia.org)

Estimated timelines

Total time – from 2 days. Order the setup — get a clean history and worry-free releases.