Table of contents
- General concept
- Set up the whole environment
- Make local changes in DEV and get them in PROD
- Get new improvements from upstream
This is not the simplest use-case but it is very common for people who want a reasonable guarantee that their production Tiki will work with no regression, and who want to be able to use versioning for rolling back in case anything is wrong.
We have two environments (or more).
- DEV is a Tiki server for improving the Tiki site. It may break sometimes before it gets better. It gets updates from the official Tiki repo (-+upstream+-) and it pushes updates and local changes to the local repo (-+origin+-).
- PROD is the production Tiki which should only be updated from
originafter everything was tested on DEV or on another server like a preprod or acceptance Tiki instance. preprod or acceptance are out of the scope of this document and will not be mentioned again.
Let's imagine a Tiki site running Tiki 22.x
This will hold a full Tiki repo, plus local changes such as custom theme, custom templates, logos and favicons, local improvements not yet contributed to the community or contributed in another branch (like contributed in master while running 22.x)
For instance let's create a local_repository repo on gitlab with options:
x Not initialised
The URL is :
git at gitlab.com:xxxxx/local_repository.git
Get a full repo (yes, it's big) from official sources.
dev:~$ git clone https://gitlab.com/tikiwiki/tiki.git dev_tiki22
We now have a full repo in folder
dev_tiki22 (place folder as suits your local environment)
dev:~/dev_tiki22$ git remote origin dev:~/dev_tiki22$ git remote rename origin upstream dev:~/dev_tiki22$ git remote add origin firstname.lastname@example.org:xxxxx/local_repository.git dev:~/dev_tiki22$ git remote -v origin email@example.com:xxxxx/local_repository.git (fetch) origin firstname.lastname@example.org:xxxxx/local_repository.git (push) upstream https://gitlab.com/tikiwiki/tiki.git (fetch) upstream https://gitlab.com/tikiwiki/tiki.git (push)
dev:~/dev_tiki22$ git fetch --all Fetching upstream Fetching origin dev:~/dev_tiki22$ git push -u origin --all Counting objects: 549383, done. Delta compression using up to 12 threads. Compressing objects: 100% (133718/133718), done. Writing objects: 100% (549383/549383), 1.32 GiB | 7.90 MiB/s, done. Total 549383 (delta 430804), reused 525638 (delta 410223) remote: Resolving deltas: 100% (430804/430804), done. remote: Checking connectivity: 549383, done. To gitlab.com:xxxxx/local_repository.git * [new branch] 22.x -> 22.x Branch '22.x' set up to track remote branch '22.x' from 'origin'.
Could anyone explain why we end up in 22.x instead of master?
We want that checkouts and pull and push default to
origin instead of
dev:~/dev_tiki22$ git checkout 21.x Branch '21.x' set up to track remote branch '21.x' from 'upstream'. Switched to a new branch '21.x'
dev:~/dev_tiki22$ git push -u origin --all Branch '22.x' set up to track remote branch '22.x' from 'origin'. Branch '21.x' set up to track remote branch '21.x' from 'origin'.
All is fixed now but creating a new branch sets it to upstream again instead of origin. This is an accident waiting to happen (pushing local stuff on the official Tiki repository). any idea?
dev:~/dev_tiki22$ git checkout 19.x Branch '19.x' set up to track remote branch '19.x' from 'upstream'. Switched to a new branch '19.x'
We need to remember to run
git push -u origin --all
We can save space by installing a light source version with no history.
prod$ git clone --depth=1 --branch=22.x email@example.com:xxxxx/local_repository.git tiki_prod_22
dev:~/dev_tiki22$ cp templates/tiki-listpages.tpl themes/templates dev:~/dev_tiki22$ git status On branch 22.x Your branch is up to date with 'origin/22.x'. Untracked files: (use "git add <file>..." to include in what will be committed) themes/templates/tiki-listpages.tpl dev:~/dev_tiki22$ git commit themes/templates/tiki-listpages.tpl -m "First local modification" dev:~/dev_tiki22$ git push
dev:~/dev_tiki22$ git pull
dev:~/dev_tiki22$ git pull --rebase --autostash
(needs testing and confirmation)
After some testing in DEV, update PROD
prod:~/repo_prod_22$ git pull
Use tags for updating PROD. That would make rolling back PROD easier.