Вопросы Теги

Fork vs Branch vs other option для проекта [duplicate]

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

Что вы можете сделать, это использовать селектор CSS3: псевдо classe nth-child() 

#list>* {
  display: inline-block;
  padding: 20px 28px;
  margin-right: 5px;
  border: 1px solid #bbb;
  background: #ddd;
  color: #444;
  margin: 0.4em 0;
}

#list :nth-child(-n+4) {
  color: #600b90;
  border: 1px dashed red;
  background: orange;
}
The oranges elements are the previous sibling li selected using li:nth-child(-n+4)




  1
  
2

  
3

  
4

  
5

  
6

  
7

  
8

  
9

Ограничения

  • Вы не можете выбрать предыдущие элементы основанный на классах следующих элементов
  • Это то же самое для псевдо классов

218
задан reprogrammer 31 August 2010 в 18:05
поделиться

4 ответа

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

Викинг - это не что иное, как клон на GitHub на стороне сервера:

  • без возможности прямого нажатия
  • с добавленной функцией fork queue для управления запросом на слияние

Вы сохраняете вилку в синхронизации с исходным проектом с помощью:

  • добавления исходного проекта в качестве удаленного
  • регулярного извлечения из этого исходного проекта
  • отмените текущую разработку в верхней части интересующей вас отрасли, которую вы обновили из этой выборки.

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

Цель - действительно разрешить сотрудничество, хотя участие direct не всегда возможно.

Тот факт, что вы клонируете на стороне GitHub, означает у вас теперь есть два «центрального» репозитория («центральный» как «видимый от нескольких соавторов»). Если вы можете добавить их непосредственно в качестве соавторов для проекта one , вы не

Опыт слияния будет примерно одинаковым, но с дополнительным уровнем косвенности (нажмите сначала вилка, затем попросите вытащить, с риском развития на исходном репо, чтобы ваши быстрые слияния не ускорялись вперед). Это означает, что правильный рабочий процесс - git pull --rebase upstream (rebase ваша работа поверх новых коммитов от восходящего потока), а затем git push --force origin, чтобы переписать историю таким образом, ваши собственные фиксации всегда находятся поверх коммитов исходного (восходящего) репо.

См. также:

227
ответ дан Community 17 August 2018 в 19:22
поделиться
  • 1
    Мы разрабатываем проект в доме, и нет никаких проблем с добавлением людей в качестве соавторов. Но мы хотели бы понять, может ли разветвление проекта привести к слиянию изменений в основной проект. – reprogrammer 31 August 2010 в 18:05
  • 2
    @reprogrammer: если вы можете добавить коллаборационистов, то разветвление не требуется. они могут перегруппироваться локально, а затем слить на целевую ветку, а затем нажать прямо на центральное репо one , вместо того, чтобы управлять центральным репо two (исходным и fork) , Перестановка будет примерно одинаковой, но с дополнительной косвенностью, когда задействована вилка. Опять же: здесь не нужно. Я обновил свой ответ. – VonC 31 August 2010 в 18:09
  • 3
    Честно говоря, даже если вам это не нужно, всегда полезно, чтобы имел священное репо, доступное только для старших разработчиков, лидеров команд или других «доверенных». люди . Все остальные члены команды должны работать в своих вилках (песочницы) и вносить свои изменения в форму запроса на растяжение. Поскольку DVCS позволяет, мы адаптировали его как «наилучшую практику». и успешно использовать это даже в самых маленьких проектах ... – intland 26 April 2012 в 13:07
  • 4
    @intland, чтобы вы больше выступали за «рабочий процесс интеграции-менеджера»; как описано в stackoverflow.com/users/6309/vonc?tab=responses , то? Для того, чтобы представить Git в большом корпусе, я сначала предпочитаю централизованный рабочий процесс (более знакомый для всех), прежде чем перейти к «Integration-manager». один. – VonC 26 April 2012 в 14:26
  • 5
    Мы должны назвать forks "веточки" так как они разбиты веткой и используются для запуска целого нового дерева. Только мои два цента - мне нравится древняя идиома. – Eric 13 January 2015 в 01:17
50
ответ дан Aidan Feldman 17 August 2018 в 19:22
поделиться

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

Общий шаблон выглядит следующим образом:

  • Заставьте исходный репозиторий проекта иметь свою собственную копию GitHub, после чего вам будет разрешено нажимать изменения.
  • Клонировать репозиторий GitHub на вашем локальном компьютере
  • Необязательно добавьте исходный репозиторий в качестве дополнительного удаленного репозитория в вашем локальном репозитории. Затем вы сможете получать изменения, опубликованные в этом репозитории.
  • Внесите ваши изменения и ваши собственные локальные записи.
  • Нажмите свои изменения в репозиторий GitHub (как вы обычно выиграли «У вас есть права на запись в репозиторий проекта напрямую».
  • Обратитесь к сопровождающим проекта и попросите их получить ваши изменения и просмотреть / слить, а также позволить им вернуться в репозиторий проекта (если вы и их захотите).

Без этого для публичных проектов довольно необычно позволять кому-либо прямо нажимать свои собственные коммиты.

41
ответ дан Bruno 17 August 2018 в 19:22
поделиться
  • 1
    Вы уверены, что толчок и тяга - правильные условия? – Ben 4 April 2014 в 17:49
  • 2
    @RecoJohnson, ну ... я не использовал слово & quot; pull & quot; в моем ответе (но «pull» эффективно «извлекает» + «слияние» в терминах Git). Какое использование «push & quot; как вы думаете, это неправильно? – Bruno 4 April 2014 в 18:31
  • 3
    @RecoJohnson Вы, как вкладчик, нажимаете на свою вилку GitHub; работники проекта вытаскивают ваш вклад из вашей вилки. – mljrg 14 May 2014 в 12:03
  • 4
    Я полагаю, что предположение о том, что вы вряд ли назначаете сотрудника, более верно в мире с открытым исходным кодом, чем во многих организациях с группами разработчиков, которые теперь используют git, где команда разработчиков хорошо определена. Я думаю, что это важное различие, и сделать это недостаточно, вероятно, потому, что компании, такие как gitlab, процветают, потому что они понимают потребности предприятия и нуждаются в контроле. – code4cause 20 January 2017 в 18:20

Forking создает совершенно новый репозиторий из существующего репозитория (просто делает git clone на gitHub / bitbucket)

Форкс лучше всего использовать: когда целью «split» является создание логически независимый проект, который никогда не может воссоединиться со своим родителем.

Стратегия филиала создает новую ветвь по существующему / работающему репозиторию

Филиалы лучше всего использовать: когда они создаются как временные места для работы через функцию с намерением объединить ветвь с источником.

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

Эта проблема решается вилками: в любое время, когда разработчик хочет что-то изменить в проекте с открытым исходным кодом, они не клонируют официальный репозиторий. Вместо этого они развивают его, чтобы создать копию. Когда работа завершена, они делают запрос на перенос, чтобы владелец репозитория мог просмотреть изменения и решить, объединить ли их с его проектом.

В своем ядре forking похож на ветвление функции, но вместо создания ветвей создается вилка репозитория, и вместо выполнения запроса слияния вы создаете запрос на перенос.

Ниже ссылки дают разницу в хорошо объясненном виде:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https: / /buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html

0
ответ дан srinivas y 17 August 2018 в 19:22
поделиться
  • 1
    "Лучше всего использовать" заявления в этом ответе, похоже, игнорируют многие проблемы, которые препятствуют тому, чтобы ветвление работало на такие вещи, как проекты с открытым исходным кодом, а также на реальность использования вилок в реальном мире. Чрезвычайно часто встречаются вилки, используемые в сочетании с запросами на тягу, чтобы люди могли сотрудничать в проекте, у которого не все есть разрешения на изменение данного репозитория напрямую. – StriplingWarrior 26 March 2018 в 17:41
Другие вопросы по тегам:

Похожие вопросы: