Git sync что это
Перейти к содержимому

Git sync что это

  • автор:

Про Git на пальцах (для переходящих с SVN)

Год назад мы с командой решили перейти с SVN на Git. Зачем это было надо — писать не буду, т.к. на эту тему уже и так много написано. А хочу я описать типичные алгоритмы работы, понятные человеку, который долгое время пользовался SVN. Ниже — памятка, написанная для команды год назад, чтобы легче было мигрировать. Надеюсь, кому-нибудь пригодится.

Немного об устройстве Git (упрощённо).

Git — распределённая VCS. Это значит, что мы работаем не с одним репозитарием на сервере, а каждый имеет у себя локальную копию репозитария. Соответственно, такие операции, как checkout и commit производятся с локальным репозитарием. Друг с другом же (или с тем, что на сервере) репозитарии синхронизируются специально предназначенными командами pull (fetch) и push.

Это удобно. Это позволяет коммитить столь часто, сколь угодно, даже если в данный момент отсутствует соединение с сервером.

Важное преимущество Git’а — внятная работа с ветками и удобный механизм слияний (merge). В SVN мы, как правило, работали с одной веткой trunk (в git ветка, с которой мы работаем по умолчанию, называется master). Эта же ветка заливалась на продакшн. Главное неудобство здесь — то, что если мы производим какие-то изменения, или разрабатываем новый функционал, мы вынуждены либо сидеть и не коммитить до тех пор, пока задача не будет доделана до конца, либо (если нам нужна помощь коллеги), закоммитить недоделанный функционал, как есть, сделав таким образом trunk непригодным к заливке на продакшн. Особенно это неприятно, если новый функционал делается не один день, а в это время возникает необходимость что-нибудь срочно починить в рабочей системе.

Надо отметить, что в SVN, конечно, есть ветки, но сделаны они, видимо, для другого, и поэтому плохо приспособлены для того, чтобы их сливать в trunk. В git операция merge сделана изящно и удобно, что позволяет нам существенно изменить workflow на более оптимальный.
Ещё одно отличие git в том, что он хранит не изменения, а текущее состояние проекта в каждый момент времени.

О главном.
  1. master — это та ветка, которая всегда, в любой (!) момент должна быть готова к деплою на продакшн.
  2. Поэтому мы никогда не делаем новые фичи и багфиксы сразу в master, используем для этого ветки.
  3. Полезно будет изучить статьи 1234 и, возможно, даже Git book. В статье №2 oleganza сформулировал очень важный принцип: одна фича — одна ветка. Один багфикс (если предполагается длиннее двух коммитов) — одна ветка. Один эксперимент — одна ветка. Одна фича внутри эксперимента — ветка от ветки.
  4. Всегда пишем вразумительные комментарии к коммитам.
  5. После того, как фича (багфикс) написаны, оттестированы и готовы к продакшну, мержим ветку в master.

Поэтому, хорошим правилом будет, всё же, создание отдельной ветки (за исключением совсем уж простых случаев).

Настройка.

$ git config —global user.name «First Last»
$ git config —global user.email «email@example.com»
$ git config —global color.diff «auto»
$ git config —global color.status «auto»
$ git config —global color.branch «auto»

Дополнительно можно настроить shell-alias’ы, как описано в статье №2.

Cтандартный workflow.
Шаг 1. Начало работы — клонирование репозитария.

Предполагается, что у вас уже есть и настроен gitosis, на котором лежит проект.

git clone gitosis@git.yourserver.com:yourproject.git — этот шаг делается один раз.

Результатом будет папка yourproject с проектом у вас на жёстком диске. Команда clone делает следующие вещи: клонирует удалённый репозитарий в новую папку (yourproject в данном случае), создаёт в локальном репозитарии remote-tracking ветки для всех веток удалённого репозитария, создаёт локальную копию активной в данный момент удалённой ветки и делает из неё checkout.

Шаг 2а. Написание нового кода или багфикс.

1. git branch — смотрим, какие ветки у нас есть в данный момент в репозитарии. Сразу после клонирования у вас будет видна только одна, активная в данный момент в удалённом репозитарии, ветка (в нашем случае это по умолчанию master, т.к. удалённый репозитарий находится на сервере и в нём ветки никто не переключает). Если в репозитарии есть другие ветки, их можно увидеть, добавив ключ -a (активная ветка обозначена звёздочкой):

$ git branch -a
* master
origin/HEAD
origin/master
origin/feature

2. Допустим, мы хотим заимплементить фичу feature. Создаём локально новую ветку с помощью команды branch. Командой checkout можно переключаться между ветками:

$ git branch feature
$ git checkout feature
Switched to branch «feature»

Или, что тоже самое, только короче:

$ git checkout -b feature
Switched to a new branch «feature»

3. В git есть такое понятие как индекс. Например, команда commit добавляет в репозитарий только те файлы, которые есть в данный момент в индексе. Поэтому, во время работы не забываем добавлять (git add ) или удалять (git rm ) файлы в/из индекса репозитария. Обратите внимание, что, в отличие от SVN, если вы изменили файл, его заново нужно добавить в индекс командой git add.

$ git add file1 file2
$ $ git commit -m «adding file1 & file2»
Created initial commit 8985f44: adding file1 & file2
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 file1
create mode 100644 file2

Здесь есть полезности: команда git add . добавляет все untracked файлы в индекс (рекурсивно), а ключ -a у команды commit позволяет автоматически добавить все модифицированные (но не новые!) файлы.

Текущее состояние индекса можно посмотреть командой git status:

$ git status
# On branch feature
# Changes to be committed:
# (use «git reset HEAD . » to unstage)
#
# new file: file1
# new file: file2
#

Коммиты в репозитарии смотрятся командой git log.

4. Если мы хотим разрабатывать новый функционал совместно, нам нужно опубликовать нашу ветку на сервере, чтобы другие могли с ней работать. Вот как это делается (перед этим необходимо закоммитить все изменения в данной ветке):

$ git push origin feature:refs/heads/feature
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitosis@git.yourserver.com:yourproject.git
* [new branch] feature -> feature

(в новых версиях git можно просто git push origin feature:feature)

Команда push отправляет изменения в удалённый репозитарий (origin) из локальной ветки feature в удалённую ветку featurе, предварительно создав её там (refs/heads/feature нужно как раз для создания ветки). В дальнейшем можно будет использовать git push origin feature (по умолчанию git push публикует изменения из всех веток).

Но при таком способе публикации, не устанавливается связь между локальной версией ветки и опубликованной. Т.е. если кто-то закоммитит изменения в эту удаленную ветку и вы сделаете git pull, то будет ошибка:

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From gitosis@git.yourproject.com:yourproject
d23a39c..b0a86e0 feature -> origin/feature
You asked me to pull without telling me which branch you
want to merge with, and ‘branch.feature.merge’ in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. ‘git pull ‘).
See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

See git-config(1) for details.

Т.е. гит не знает с какой ветки ему мерджить. Поэтому можно либо каждый раз указывать это руками:

git pull origin feature

Либо прописать в конфиге:

git config branch.feature.remote origin
git config branch.feature.merge refs/heads/feature

Кроме того можно воспользоваться скриптиком от William Morgan и делать git publish-branch feature вместо всего остального.

Шаг 2б. Как присоединиться к работе над веткой.

Предполагается, что вы уже склонировали себе репозитарий.
Главное здесь — правильно подключить удалённую ветку. Сделать это можно с помощью ключа —track команды git checkout. Команда, приведённая ниже, создаёт локальную ветку feature и подключает её к удалённой ветке origin/feature, после чего переключается в эту ветку.

$ git checkout —track -b feature origin/feature
Branch feature set up to track remote branch refs/remotes/origin/feature.
Switched to a new branch «feature»

Это важно на данном этапе, поскольку просто команда pull смержит удалённую ветку к нам в master, а это не то, что нам нужно.

Далее можно работать аналогично описанному в шаге 2а, синхронизируя репозитарий в каждой из веток командами git pull и git push.

Шаг 2в. Как переключиться в другую ветку, когда в текущей есть изменения и коммитить их рано.

Иногда возникает необходимость срочно переключиться в другую ветку, например для багфикса. Но на полноценный коммит в этой ветке еще не хватает. Для этого существует команда git stash:

$ git status
# On branch feature
# Changes to be committed:
# (use «git reset HEAD . » to unstage)
#
# new file: somefile
#
$ git stash
Saved working directory and index state «WIP on feature: b0a86e0. blabla»
HEAD is now at b0a86e0 blabla
(To restore them type «git stash apply»)
$ git status
# On branch feature
nothing to commit (working directory clean)

Теперь можно смело переключаться в другую ветку и работать там.

По возвращению в эту ветку, необходимо сделать git stash apply:

$ git stash apply
# On branch feature
# Changes to be committed:
# (use «git reset HEAD . » to unstage)
#
# new file: somefile
#

Шаг 3. merge и rebase.
  1. Вы хотите подлить свежие изменения из master к себе в ветку;
  2. Вы хотите слить свою ветку в master.

Подливаем изменения из master в рабочую ветку feature, ветку feature нигде не публикуем, работаем с ней только локально:

$ git checkout feature
Switched to branch «feature»
$ git rebase master
First, rewinding head to replay your work on top of it.
HEAD is now at 89f6a20 file2
Applying feature1

Сливаем изменения из рабочей ветки feature в master, ветка feature нигде не публиковалась, никто из коллег с ней не работал:

$ git checkout master
Switched to branch «master»
$ git rebase feature
First, rewinding head to replay your work on top of it.
HEAD is now at 9bfac0a feature1
Applying file2

Подливаем изменения из master в рабочую ветку feature, ветка feature опубликована на удалённом репозитарии, с ней также работают коллеги:

$ git checkout feature
Switched to branch «feature»
$ git merge master
Merge made by recursive.
file2 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file2

Сливаем изменения из рабочей ветки feature в master, ветка feature публиковалась на удалённом репозитарии для совместной работы:

$ git checkout master
Switched to branch «master»
$ git merge feature
Merge made by recursive.
feature1 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 feature1

Шаг 4. Удаление ветки.

После того, как мы закончили работать с веткой и слили изменения в master (или в другую ветку), можно удалить ветку.

Для удаления локальной ветки:

$ git branch -d feature
Deleted branch feature.

Для удаления remote tracking ветки:

$ git push origin :feature
— [deleted] feature

Вот, вроде, и всё. Этого должно быть достаточно в первое время при миграции с SVN на Git.

Отдельное спасибо хабраюзеру mironov_anton за всяческие дополнения и улучшения данного текста.

Synchronize Git repositories

Синхронизировать репозиторий Git с новыми операциями в первоначальном репозитории SVN очень просто, что обеспечивает удобство во время переходного периода, когда вы можете продолжать пользоваться текущим рабочим процессом SVN и параллельно начинать экспериментировать с Git.

Можно выполнять синхронизацию в обоих направлениях. Но мы рекомендуем одностороннюю синхронизацию от SVN к Git. Во время переходного периода следует использовать только репозиторий SVN, а не репозиторий Git. Когда вы уверены, что ваша команда готова к переходу, вы можете завершить процесс перехода и начинать размещение изменений в Git вместо SVN.

Пока вам следует продолжать размещение данных в репозитории SVN и синхронизацию репозитория Git по мере необходимости. Этот процесс схож с этапом преобразования, но т.к. вы имеете дело только с фрагментарными изменениями, процесс должен быть более продуктивным.

Обновление файла авторских данных

Файл authors.txt, который использовался для преобразования имен пользователей SVN в полные имена и адреса электронной почты, важен для процесса синхронизации. Если он был перемещен из ~/GitMigration/authors.txt, которое мы использовали ранее, вам необходимо обновить его расположение с помощью:

git config svn.authorsfile 

Если новые разработчики вносили изменения в репозиторий SVN после прошлой синхронизации (или первоначального клонирования), необходимо обновить файл авторских данных. Это можно сделать вручную, добавляя новых пользователей в authors.txt, или же можно использовать опцию —authors-prog, как описано в предыдущем разделе.

Для разовой синхронизации зачастую проще непосредственно отредактировать авторский файл, а опцию —authors-prog рекомендуется использовать при выполнении неконтролируемых синхронизаций (запланированные задачи).

базы данных

Связанные материалы
Перемещение полного репозитория Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud

Автоматическое генерирование авторов Git

Если ваш файл авторских данных не нуждается в обновлении, можете перейти к следующему разделу.

Команда git svn включает опцию —authors-prog, указывающую на скрипт, который автоматически преобразовывает имена пользователя SVN в авторов Git. Необходимо настроить этот скрипт, чтобы он принимал имя пользователя SVN как единственный аргумент и возвращал его в одной строке в форме Имя (так же, как в правой части существующего файла авторских данных). Эта опция очень полезна, если вы периодически добавляете в проект новых разработчиков.

Если желаете использовать опцию —authors-prog, создайте файл с именем authors.sh в ~/GitMigration . Добавьте следующую строку в authors.sh, чтобы вернуть фиктивное имя Git и адрес электронной почты авторам, которые отсутствуют в файле authors.txt :

echo "$1 "

При этом будет создано только фиктивное имя и адрес электронной почты, основываясь на имени пользователя SVN, поэтому вы можете изменять его, если есть возможность предоставить более содержательное обозначение.

Извлечение новых поступлений SVN

В отличие от SVN, в Git имеется различие между загрузкой предыдущих поступлений и интеграцией их в проект. Первое называется «извлечением», а второе может быть выполнено посредством слияния или перебазированием. В каталоге ~/GitMigration выполните следующую команду, чтобы извлечь все новые поступления из оригинального репозитория SVN.

git svn fetch

Она похожа на команду git svn clone из предыдущего этапа в том, что она обновляет только удаленные ветви репозитория Git — локальные ветви при этом не будут отражать обновлений. С другой стороны, удаленные ветви должны точно соответствовать истории репозитория SVN.

Если вы используете опцию —authors-prog необходимо включить ее в вышеуказанную команду:

git svn fetch --authors-prog=authors.sh

Синхронизация с извлеченными поступлениями

Для применения загруженных поступлений к репозиторию, запустите следующую команду:

java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar sync-rebase

Эта команда переместит извлеченные поступления на ваши локальные ветви, чтобы они соответствовали своим удаленным аналогам. Теперь вы должны видеть новые поступления в результатах git log .

Очистка репозитория Git (повторная)

Рекомендуется снова запустить скрипт git-clean, чтобы удалить устаревшие тэги или ветви, которые были удалены из первоначального репозитория SVN с момента прошлой синхронизации:

java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git --force

Теперь ваш локальный репозиторий Git должен быть синхронизирован с репозиторием SVN.

Резюме

В этот переходный период очень важно, чтобы разработчики выполняли размещение только в оригинальном репозитории SVN. Репозиторий Git должен обновляться только в рамках синхронизации, как описано выше. Это намного проще, чем управлять рабочим процессом с двухсторонней синхронизацией, и в то же время у вас есть возможность начать интеграцию Git в процесс разработки.

Как работает Git Sync

по информации из гула, команда Sync, вызывает pull, push и update. Но не возникает ли противоречие. Если на сервере и в лок.репозитории две разные версии одного и того же файла, то что с ним станет после Sync. Будет залит вариант с сервера(как в pull), или на сам сервер зальется моя версия(push). Кажется очевидным что эти операции не должны конфликтовать, но не понимаю как.

Отслеживать
задан 1 дек 2013 в 12:16
2,434 3 3 золотых знака 26 26 серебряных знаков 42 42 бронзовых знака
Очевидно другое: на любом шаге, в случае возникновения проблем, вы получите ошибку.
1 дек 2013 в 12:22
это очевидно лишь вам
1 дек 2013 в 13:04
git help sync Нет справочной страницы для gitsync
1 дек 2013 в 13:32

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Это Вы о gui команде говорите? потому что в консоли такой команды нет и не было. Update — это вообще с svn.

@a_gura прав. По сути, вначале будут выкачаны изменения git fetch (это можно сделать всегда, если только не отключили интернет или не хватает места), потом git попытается применить их (то есть сделать merge). Часто он может сделать их автоматом. Если не получиться, то будет стандартный диалог для merge, где Вам предложат ручками решить все конфликты.

Следующим этапом будет push. Если в ветке за это время ничего не случилось, то он пройдет без проблем. Если же там что то поменялось, то будет снова pull, а потом push.

Команда git-sync: опции, ключи и примеры использования

Общие команды – Общие команды, присущие различным операционным системам.

git sync

  • Sync the current local branch with its remote branch:
  • Sync the current local branch with the remote main branch:

git sync origin main

  • Sync without cleaning untracked files:

Изображение Выучи 10 хороших привычек для работы в UNIX от IBM

Примеры кода, демонстрирующие общие подходы в программировании или же решающие небольшие прикладные задачи. Языки программирования и библиотеки, позволяющие эффективно решать задачи разработки. Объектно-ориентированное программирование, функциональное программирование и прочие подходы и …

Фото Код

Трюки Bash

Полезные заметки по работе с командной строкой: bash и прочие *sh. Однострочники, скрипты, позволяющие решать большие и малые задачи администрирования и настройки Юникс систем. Zsh для современного MacOS, Bash для …

Фото Трюки Bash

Заметки о настройке различных IT-штуковин. Настройка, допиливание, полировка. Конфигурируем приложения и тюнингуем сервера. Полезные параметры и ключи запуска программ. Увеличиваем скорость, уменьшаем отклик, ускоряем работу и улучшаем результаты работы. Объясняем …

Фото Настройки

Терминал/Консоль

Команды и инструкции терминала (консоли) Linux, MacOS, Windows и прочих операционных систем. Трюки и особенности командных оболочек, скрипты для администрирования Unix. Программирование и скриптование Windows и Linux, тонкая настройка Macos. …

Фото Терминал/Консоль

Также может быть вам интересно:

  • Как получить дерево директорий на Bash одним однострочником
  • Python: Функции
  • Python: Встроенные типы данных (list, set, dict, etc)
  • Python: типы данных, переменные, логическое ветвление и циклы
  • Как сделать свою middleware в Django (с примерами)

Свежее на «Цифре»
MessageId или как дебажить систему с минимумом проблем
Программы, 50 дней назад
Проверочный список для выпуска промышленных приложений с иллюстрациями
Работа и управление, 91 день назад
В Google Pixel и Windows Snipping Tool есть возможность восстановления обрезанных изображений
Новости, 23.03.2023
Два подарка «под ёлочку» от Heroes of Might and Magic
Новости, 25.12.2022
Вышел Pulsar – редактор кода на основе Atom
Новости, 25.12.2022
Ленивый backup PostgreSQL
Программы, 17.12.2022
Google анонсировала OSV-Scanner: сканер уязвимостей в программных проектах
Новости, 16.12.2022

Фото Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

На днях группа бывших разработчиков Gitea решили создать на базе хостинга кода Gitea свою версию проекта – «Forgejo». Причиной тому …

Фото Пользователи и их создание в Django - своя регистрация на сайте

Пользователи и их создание в Django — своя регистрация на сайте

Если вашим сайтом должны активно пользоваться несколько человек, то полезно их различать, а значит — надо уметь создавать пользователей, либо …

Фото Новый синтаксис старой команды with в Python 3.10

Новый синтаксис старой команды with в Python 3.10

Как же долго моё чувство прекрасного страдало… Но в Python 3.10 появился новый парсер синтаксических конструкций Python!

Фото Добавляем постраничную пагинацию на Django сайт

Добавляем постраничную пагинацию на Django сайт

На сайтах часто встречаются многостраничные объекты: список товаров, список заметок и т.д. Поэтому важно уметь добавить навигацию по страницам на …

Фото Новый оператор match-case в Python

Новый оператор match-case в Python

В новой версии Python (3.10) появится новый оператор. Новый оператор сопоставления по шаблону (match-case).

Фото Нет слов, одни. однострочники

Нет слов, одни. однострочники

На днях вышел пост со списком полезных однострочников для JavaScript программистов. Памятуя Perl-овую молодость, заглянул туда.

Фото Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если …

Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать …

Фото Разграничение прав доступа на Django сайте

Разграничение прав доступа на Django сайте

Почти на любом веб-сайте необходимо разделять пользователей на группы и предоставлять им разные возможности. В Django есть довольно серьёзная система …

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *