Блог

В нашей команде только человеку B разрешено отправлять изменения в наш удаленный репозиторий. Другие разработчики, такие как person A, создают форк этого удаленного репозитория. Лицо В должно позаботиться о том, чтобы изменения лица А попали в удаленный репозиторий.

Допустим, что пользователь A совершил коммит в своем разветвленном репозитории. Затем пользователь B клонирует репозиторий пользователя A. Человек А вносит некоторые изменения в свое репо. Затем пользователь B хочет извлечь эти изменения в своем репозитории, который он клонировал ранее от пользователя A. Это позволяет пользователю B отправлять изменения пользователя A в удаленное репозиторий. Возможно, этот человек должен внести еще несколько изменений. Человек B также должен иметь возможность извлекать эти изменения и отправлять их в удаленное хранилище.

Мы не уверены, как это сделать с помощью git. Какие-нибудь советы?

Это команды, которые пытается выполнить пользователь B:

 git clone reponame-from-person-a.git
cd reponame-from-person-a
git checkout branch-from-person-a
git commit --amend --author="Person B <person.b@company.com>"
git remote remove origin
git remote add origin reponame-from-person-b.git
git push --set-upstream origin branch-from-person-a
git push -f
 

Затем, когда человек А внес еще несколько изменений, человек Б пробует это:

 git pull
 

Чего мы ожидаем, так это того, что теперь будут извлечены последние изменения от person A. К сожалению, это не так.

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

• Пользователь A фиксирует изменения и открывает запрос на извлечение, указывающий, из какой ветви разветвленного репозитория он должен слиться с какой ветвью удаленного репозитория (репозитория пользователя B)
• Человек B просматривает изменения и объединяет их.

Обратитесь к этому для получения более подробной информации.

Поскольку git это распределенный VCS, все это клонирование не требуется после того, как все получили копию.

Например:

 Origin:
      master
        |
A---B---C
 

Персона А разветвляется и создает feature ветку:

 Person A:
  origin/master
        |
A---B---C---D---E
                |
             feature
 

идите вперед и позвольте Человеку А подтолкнуть его к Источнику:

 Origin:
      master
        |
A---B---C---D---E
                |
             feature
 

feature будет находиться на удаленном сервере, но изменения не origin/master внесены, поскольку вы определили, что только пользователю B разрешено вносить изменения master . Существование feature на удаленном сервере вообще не влияет origin/master .

На этом этапе пользователь B, у которого ЕСТЬ полномочия для включения feature в master , может выполнить выборку, чтобы получить обновленную «копию всего», после чего он может выполнить слияние, создав фиксацию слияния F из master и feature :

 Person B:
  origin/master
        |
A---B---C-------F
              /
          D---E
              |
           feature
 

Обратите внимание, что изменения все еще не origin/master внесены. Все изменения пока касаются только филиала местного репо Персоны Б. master :

 Person B:
origin/master  master
        |       |
A---B---C-------F
              /
          D---E
              |
           feature
 

Изменения все еще не origin/master внесены . (Я разбираю это шаг за шагом). Только после того, как пользователь B перейдет master в Origin, он будет обновлен в Origin, что разрешено делать только пользователю B.:

 Origin:
              master
                |
A---B---C-------F
              /
          D---E
              |
           feature
 

На протяжении всего этого процесса отслеживается авторство и приверженность. Любой, кто получит репозиторий на этом этапе, увидит feature , что текст, написанный человеком А, был объединен и включен master человеком В

Не уверен в том, как работает ваша команда, но никогда раньше не видел такого рабочего процесса. Пользователь B не должен клонировать репозиторий пользователя A. Я рекомендую вам ознакомиться с этой простой статьей !