Git sync что это
Синхронизация хранилища 1С с репозиторием git
Проект gitsync представляет собой:
Через пакетный менеджер opm
Запасной споcоб, например, когда на сервере нет доступа к Интернет
Отличия от gitsync версий 2.x
Раздел документации в разработке
Использование приложения gitsync
Подготовка нового репозитория (локального)
Данный шаг можно пропустить, если у Вас уже есть локальный репозиторий git
Синтаксис команды: gitsync clone [ОПЦИИ] PATH URL [WORKDIR]
Команда создаст локальный репозиторий в указанном каталоге путем копирования удаленного.
Больше примеров: gitsync usage clone
Синтаксис команды: gitsync init [ОПЦИИ] PATH [WORKDIR]
Вариант для подключения к хранилищу по протоколу http
Больше примеров: gitsync usage init
Установка соответствия пользователей
Данный шаг можно пропустить, если у Вас уже установлено соответствие пользователей хранилища 1С и git
С помощью e-mail выполняется связка пользователя с публичными репозиториями (например, Github или Bitbucket)
Установка номера начальной версии хранилища 1С для синхронизации
Данный шаг можно пропустить, если у Вас уже установлен номер версии в файле VERSION
Пример файла, в котором указано, что выгружено 10 версий:
gitsync set-version (необязательный)
Больше примеров: gitsync usage set-version
Справка по использованию команды
Глобальные переменные окружения
| Имя | Описание |
|---|---|
| GITSYNC_V8VERSION | маска версии платформы (8.3, 8.3.5, 8.3.6.2299 и т.п.) |
| GITSYNC_V8_PATH | путь к исполняемому файлу платформы 1С (Например, /opt/1C/v8.3/x86_64/1cv8) |
| GITSYNC_VERBOSE | вывод отладочной информации в процессе выполнения |
| GITSYNC_TEMP | путь к каталогу временных файлов |
| GITSYNC_EMAIL | домен почты для пользователей git |
Переменные окружения команды
| Имя | Описание |
|---|---|
| GITSYNC_WORKDIR | рабочий каталог для команды |
| GITSYNC_STORAGE_PATH | путь к хранилищу конфигурации 1С. |
| GITSYNC_STORAGE_USER | пользователь хранилища конфигурации |
| GITSYNC_STORAGE_PASSWORD | пароль пользователя хранилища конфигурации |
Значения по умолчанию
gitsync sync C:/Хранилище_1С/ C:/GIT/src
Вариант вызова команды в текущем рабочем каталоге
переменная окружения GITSYNC_WORKDIR не должна быть задана
Команда выполнит выгрузку версий хранилища 1С из C:/Хранилище_1С/ в репозиторий git в каталоге C:/work_dir
Вариант с указанием пользователя хранилища и пароля
Имя пользователя = Admin, пароль = Secret.
Использование синонимов (короткая версия предыдущего примера)
Указание исполняемого файла нужной версии платформы
Команда синхронизации будет выполнена с использованием исполняемого файла платформы /opt/1C/v8.3/x86_64/1cv8 (приведен синтаксис для linux; вариант для Windows см. ниже).
Вызов команды без указания параметров, с использованием переменных окружения
Настройка плагинов синхронизации
Данный пункт можно пропустить, если Вам не требуется дополнительная функциональность синхронизации
Для расширения функциональности синхронизации предлагается механизм плагинов. Данный механизм реализован через подписки на события синхронизации, с возможностью переопределения стандартной обработки.
Больше примеров: gitsync usage plugins
Список предустановленных плагинов:
Использование библиотеки gitsync
Раздел документации в разработке
Доработка и разработка плагинов
Механизм подписок на события
Раздел документации в разработке
Проект gitsync поддерживает ряд подписок на события
Сборка производится в 2-х режимах:
Сборка обычного пакета (без зависимостей)
В этом варианте в сборку не добавляются предустановленные пакеты. Их надо будет устанавливать отдельно.
Сборка пакета с зависимостями
В сборку будут добавлены пакеты из репозиториев:
Доработка проводится по git-flow. Жду ваших PR.
Git sync что это
Synchronize tracking repositories.
This scrips intends to sync near-automatically via git in «tracking» repositories where a nice history is not as crucial as having one.
2012-2018 by Simon Thum and contributors, licensed under CC0
Suppose you have a set of text files you care about, multiple machines to work on, and a central git repository (a.k.a. bare reporitory) at your disposal. You do not care about atomic commits, but coarse versioning and backup is grave. For example, server configuration or org-mode files.
In that case, git-sync will help you keep things in sync.
Unlike the myriad of scripts to do just that already available, it follows the KISS principle: It is safe, small, requires nothing but git and bash, but does not even try to shield you from git. It is non-interactive, but will cautiously exit with a useful hint or error if there is any kind of problem.
It is ultimately intended for git-savvy people. As a rule of thumb, if you know how to complete a failed rebase, you’re fine.
For a really nice explanation in an advanced use case, have a look at this blog post:
Tested on msysgit and a real bash. In case you know bash scripting, it will probably make your eyes bleed, but for some reason it works.
It will likely get from you from a dull normal git repo with some changes to an updated dull normal git repo equal to origin. It does this by commiting, pulling & pushing as appropriate.
Care has been taken that any kind of problem, pre-existing or not, results in clear error messages and non-zero return code, but of course no guarantee can be given.
The intent is to do everything that’s needed to sync automatically, and resort to manual intervention as soon as something non-trivial occurs. It is designed to be safe in that git-sync will likely refuse to do anything not known to be safe.
You can invoke git-sync in «check» mode, in which git-sync will not do anything except return zero if syncing may start, and non-zero if manual intervention is required.
How am I supposed to use it?
Mode can be empty, sync, or check.
In «check» mode, it will indicate if syncing may start. This is useful to see if manual intervention is required (indicated by text and non-zero exit code).
In sync mode (the default), just calling git-sync inside your repository will sync with the current branches remote, if that branch is enlisted. The repository must not be in the middle of a rebase, git-am, merge or whatever, not detached, and untracked files may also be treated as an obstacle (see Options). However, sync is likely to just work. Else, a clear error message should appear.
If you don’t sync in an intertwined manner (from multiple repositories/machines), git-sync is virtually guaranteed to succeed. When required git-sync will try to rebase, which may fail. This is when you’ll need your git skills.
The flow is roughly:
On the first invocation, git-sync will ask you to enlist the current branch for sync using git config. This has to be done once for every repository (and branch, for completeness).
Because git-sync rebases, the order of commits does not always reflect the order of changes. However auto-commit records the originating machine name and time by default.
Tells git-sync to invoke auto-commit even if new (untracked) files are present. Normally you have to commit those yourself to prevent accidential additions. git-sync will exit at stage 3 with an explanation in that case.
A string which will be used in place of the default commit message (as shown below).
A string which is being eval’ed by this script to perform an auto-commit. Here you can run a commit script which should not leave any uncommited state. The default will commit modified or all files with a more or less useful message.
By default, commit is done using:
Or if you enable syncNewFiles :
There are also some command-line flags you can set to control the sync:
Automatically synchronize your git repository whenever a file is touched.
I declare this work to be useable under the provisions of the CC0 license.
Attribution is appreciated, but not required.
Git sync что это
This project was migrated to git-repo-sync
The reason is to prevent naming confusions.
I want to emphasize that git-sync synchronizes Git remote repositories. So, let’s use git-repo-sync name instead.
git remote repositories synchronization
gitSync synchronizes git-branches between remote git-repositories.
Synchronized branches should follow a naming convention.
The naming convention is Convention over Git.
gitSync works over HTTP only. It is because I had no chance to tune it for SSH.
gitSync synchronizes only two remote repositories for simplicity as it is a scripting solution.
gitSync do not synchronize Git-tags anymore. It’s because some popular Git-servers block Git-tags deletion.
gitSync has auto conflict solving. That allows to work on the same Git-branch simultaneously.
I.e. you can commit and merge to the same branch on both remote repositories. In case of a conflict you have to repeat your commit. More details on this in Git conflicts solving.
Scenarios of usage
If you will run git-sync.sh without parameters, then a test environment will be created.
You will get two remote and two local interconnected repositories on your machine.
Make changes there, run git-sync.sh, see behavour and results.
Imagine, there are two remote repositories. Each repository is a separate side.
You agreed that
Only branches with such the prefixes will be synchronized and visible on both sides.
Git conflicts solving
Conflicts may occur only if your do merges or commits to another side branches.
The prefix owner will win in case of any conflicts.
Commits of a loser will be rejected, but he just has to repeat merge or commits again (from his local repository) after a Git update (fetch, pull, etc).
To know if your commit was reflected first run gitSync then do a Git update (fetch, pull, etc) in your local Git repository.
Then look at Git commits log.
I’ve excluded Git-tags from synchronization. Nothing wrong with tags but there are some nervous subtleties with them.
Most of the following sections describe technical details.
if you are technically savvy, I expect you will complete everything from one day to one week. Depends on your situation and needs.
The only thing I want to say, this is really working.
I am waiting for your notes and wish you luck.
Ask me. I’ll answer on you questions ASAP.
See my contacts at it3xl.ru.
Provinding credentials for Git
I use my bash Git Credential Helper git-cred
It passes to Git credentials from enviroment variables created by Continues Intergration tools like Jenkins.
It is inegrated now with git-sync.
What to expect next
Victim Branches
I’ve temporary postponed this feature. Everybody can live without it. Although it is annoying.
We have some branches that reflect all our stands (dev, test, UAT, pre-prod).
Any commit three runs complete CI/CD processes.
It is useful to allow any team sides to put this branches at any position, on any commit.
I think it is time to add such branches into git-sync.
E.g.
victim/test-stand
victim-test-stand
Here is my glossary related to the topic.
You need to describe the prefixes and simple details of your real remote repositories in a simple config-file.
Create the same file as your_repo_some_name.sh.
Run the git-sync and pass a path to your config file as a parameter.
Run git-sync so periodically, better once in a minute.
That’s all. You may work and forget about git-sync.
In the case of any synchronization interruption git-sync will do everything right.
Use any *nix or Window machine.
About
Synchronization of two remote Git repositories. Two remotes as one. Auto conflict solving by Convention over Git. Client-Vendor conception.
Синхронизация Git-репозиториев в режиме реального времени
Oct 7, 2020 · 5 min read
Работая с клиентами на таких платформах, как Github или Gitlab, мы в Gitstart часто сталкиваемся с необходимостью синхронизировать кодовые базы между удаленными репозиториями. По каждой поставленной клиентом задаче наши разработчики работают внутри ветви частного репозитория (клона или форка клиентского репозитория), и необходима уверенность, что состояние клиентского репозитория соответствует нашему, как и наоборот. Со временем синхронизация репозиториев становится повторяющимся процессом, поэтому имеет смысл его как-то автоматизировать.
Встречайте Gitstart Fork: это наш внутренний инструмент, который использует мощь веб-хуков, чтобы синхронизировать код между парой репозиториев практически в реальном времени.
Стек технологий: большую часть кода мы пишем на TypeScript и Nodejs. В качестве базы данных мы выбрали PostgreSQL с Hasura в качестве движка GraphQL (там есть изящная функция под названием подписка, которая упрощает обработку).
Для простоты мы будем говорить о репозиториях Github, однако написанное можно распространить на любой удаленный сервис на основе git, к примеру Gitlab или Bitbucket.
1. Функции
Fork Pull предоставляет следующий функционал для синхронизации:
2. База данных
Всё начинается с таблицы, где отслеживаются оба синхронизируемых репозитория: какие ветви синхронизировать в этих репозиториях, а также любые файлы или папки, которые синхронизировать не нужно. Высокоуровневая схема будет выглядеть следующим образом:
Мы также ведем учет всех так называемых “извлечений” ( pull ), которые мы сделали:
Успешный pull регистрируется в третьей таблице, которая отслеживает пару головных коммитов синхронизированных ветвей (важность этой таблицы станет ясна в следующем разделе):
Примечание: все схемы здесь даны исключительно для того, чтобы создать общее представление. Поля можно как включать, так и исключать, в зависимости от желаемой функциональности.
3. Отслеживание изменений
Это вебхук-событие мы объединяем с щепоткой магии подписок и получаем такую последовательность событий для обнаружения изменений:
Основным триггером события pull служит обновление базы данных. В нашем случае это достигается с помощью веб-хуков благодаря их способности реагировать в реальном времени. Однако того же самого результата можно добиться и через ряд других вариантов.
Внимание: следующие шаги предполагают, что база данных актуализирована.
4. Архитектура Git
И здесь начинается настоящее веселье. На самом деле, выполнить pull не очень сложно. В качестве клиента git мы используем isomorphic-git. Операции git можно разделить на 5 этапов:
4.1 Клонирование ( clone )
Репозитории мы клонируем во временные папки. Если такие папки уже существуют, мы просто извлекаем последние коммиты и переключаемся на интересующие нас ветви. Ни удаления папок, ни повторного клонирования каждый раз не происходит, потому что pull производится быстрее, чем клонирование.
4.2 Удаление (delete)
4.3 Копирование (copy)
4.4 Добавление и коммит (Add & commit)
Простой шаг, на котором мы добавляем все пути к файлам в будущий коммит (стейджинг) и делаем коммит, получая SHA-1 головного коммита для нужд базы данных.
4.5 Отправление (push)
5. Заключение
И вот, репозитории наконец-то синхронизированы!
Это похоже на волшебство, но именно так оно и ощущается, когда технология используется изящно и с умом.
Git sync что это
There’s a bunch of web deployment systems lately that use git for uploading applications.
Deployments are not just a checkpoint in your application development, they are also something that itself needs to be developed and tested. When I use one of these systems I find myself with lots of this:
That said, git is not a bad file synchronization tool. It’s actually pretty darn fast; faster than rsync because it keeps more state around (rsync has to recheck the world each time). And it gives you a nice history of what you’ve done.
This command lets you use git like a sync tool, separate from using it as your source control. It’s written as a git extension because whatever.
You must then configure your git repository with a few commands:
You can also run a build step everytime you do a sync:
Now everytime you run git sync it will run the script in tools/build and upload the results. You can use this to run a source compressor or whatever else you might want to do before an upload. The results of your build will be committed and pushed. The commad will be run with the current working directory of the files ready to be uploaded (not your normal source repository).
You’ll still have a nice set of history of what you’ve uploaded, though that history will be strictly per-remote. It won’t be directly attached to your main repository, but the commit messages will show the relation.
About
Use git as a sync tool, without munging your source and sync VCS operations
