github: «Ссылка» частного репо на организацию - PullRequest
1 голос
/ 06 января 2012

У меня есть частный репозиторий github, в котором я работал с несколькими другими (частными) сотрудниками.Давайте назовем это repo-a .

Клиент только что добавил меня в свою учетную запись организации.Мне нужно, по сути, поделиться своим repo-a с другими разработчиками в этой Организации.Я не уверен, является ли «доля» правильным термином здесь;может мне нужно "скопировать"?Как мне поступить так?

Более важный вопрос, который, я надеюсь, кто-то может помочь, заключается в том, что я не хочу, чтобы Организация видела историю, переданную моими частными сотрудниками.Но, надеюсь, я смогу легко «отправить» последний код из repo-a в Организацию (я все еще планирую работать в частном порядке с repo-a соавторами),Это разумно возможно?

Ответы [ 3 ]

6 голосов
/ 06 января 2012

Краткий ответ: нет, это невозможно.

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

- W - X - ABCD - Y - Z - EFGH - ... (public)
       \              \
        A - B - C - D - x - E - F - G - H (private)

где ABCD - это коммит, содержащий изменения коммитов A, B, C и D, и аналогично EFGH скрывает E, F, G и H. Вы можете сделать это, используя git checkout public-branch; git merge --squash private-branch. Сквошное слияние выполняет слияние, а затем записывает его как обычный коммит, то есть без слитой ветви как родителя. Эта опция может работать для вас, если вы очень осторожны с объединением. Это все еще боль, хотя. (Обратите внимание, что слияние Y и Z приводит к дублированию коммитов в частном репо, ABCD против A-B-C-D. Это некрасиво, но лучше, чем альтернатива, которая полностью расходится в истории.)

Так что, несмотря ни на что, ваша история будет расходиться. В лучшем случае вы, вероятно, используете теги, чтобы помочь себе отслеживать вещи. Например, вы можете пометить commit D как private-0001 и commit ABCD как public-0001, commit H как private-0002 и commit EFGH как public-0002. Это, по крайней мере, позволило бы вам иметь некоторые записи о том, как отдельные истории связаны друг с другом. На самом деле вы никогда не сможете объединить какие-либо частные коммиты в публичную ветвь, поскольку коммиты приносят с собой своих предков.

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

  • Отмените свой план и сделайте частных участников публичными.

  • Сделайте так, чтобы частные авторы фиксировали ваше имя или использовали поддельные имена. (Пусть они установят user.name и user.email в .gitconfig этого репозитория.) Если все, что вы пытаетесь сделать, это сохранять их анонимными, этого будет достаточно и безболезненно.

  • Сделай это наполовину. Оглядываясь на первую диаграмму, после того, как вы сделаете сквош-слияния, все частные вкладчики будут сброшены до этой точки (перебазируя любые другие ветви, которые у них могут быть). Каждый раз, когда вы публикуете публично, вы, по сути, отбрасываете частные коммиты и рассматриваете коммит сквош-слияния как новую правду. Это потребует бдительности с вашей стороны, убедившись, что другие участники делают то, что требуется, но это избавит вас от багажа всей этой сумасшедшей истории. (Если кому-то не удастся выполнить сброс, это можно исправить. Предположим, что он совершил коммит E поверх коммита D вместо коммита ABCD. Он мог бы использовать git rebase --onto commit-ABCD commit-D для трансплантации своей ветви, где он принадлежит.) Ваша история могла бы в итоге вот так:

    - W - X - ABCD ------------------ Y - Z - EFGH - ...
       \                               \
        A - B - C - D (abandoned)       E - F - G - H (abandoned)
    

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

    - W - X - AB - X - CD - Z - ...
          |\
          | A - B (abandoned)
           \
            C - D (abandoned)
    

    Просто будьте очень, очень осторожны, чтобы отслеживать то, что вы слили в сквош. Помимо пометки, как я обсуждал ранее, вы также можете включить в свои коммиты сквош-слияния список коротких SHA1 и коммитить предметы из объединенных коммитов.

0 голосов
/ 13 января 2012

В итоге я создал новый репо repo-b и синхронизировал его с учетной записью организации. Чтобы «включить» новое изменение (я) с repo-a в repo-b , я использую команду rsync. Для справки см. принятый ответ для точной команды.

Это зависит от моей дисциплины / потока, когда обновлять репозиторий Org. Я могу синхронизировать каждый раз, когда в repo-a появляется новый коммит, или подождать, пока их будет несколько (по сути, как squash merge ). Таким образом, учетная запись Org может видеть историю моих коммитов, сохраняя анонимность моих частных соавторов.

0 голосов
/ 06 января 2012

Более важный вопрос, который, я надеюсь, кто-то может помочь, заключается в том, что я не хочу, чтобы Организация видела историю, совершенную моими частными сотрудниками.

Репозиторий Git поставляется со всей своей историей. Каждый раз. Вы можете «экспортировать» текущее состояние вашего хранилища, удалив из него папку .git/, а затем снова запустив git init. Это как бы сбрасывает вашу историю, хотя в данный момент это будет совершенно другой репозиторий.

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

Надеюсь, я правильно понял ваш вопрос.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...