Витрина Git-хранилища FOSS-проекта

Question

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

В любом случае. Я прочитал вопрос Forking an open source project nicely, но это не отвечает на мой более конкретный вопрос:

Что делать с файлами?

Прежде всего, следует ли продолжить работу с исходным хранилищем Git или просто выбросить всю историю и начать заново («rm -rf .git && git init»)? Во-вторых, существуют ли какие-либо мнения относительно старых версий readme: s, предыдущей версии и версий?

Естественно, лицензирование и атрибуция будут обрабатываться в соответствии с требованиями лицензии.

Answer 1

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

Answer 2

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

Answer 3

1. Вилка его из Github
2. клонировать его на локальном компьютере
3. Применить патчи вы послали оригинальный автор, что не были приняты
4. Нажмите

Должно быть довольно безболезненно, и это правильный способ сделать это, если вы не переписываете все с нуля.

Answer 4

причин, почему я хотел бы сохранить историю:

1. Самая важная причина: это позволяет импортировать полезные изменения из исходного кода, как они приходят в Если вы не предсказать, что ваш проект будет отличаться от. оригинал настолько тщательно, что вы никогда не захотите что-либо сделать, чтобы они появились в вашем, это значительно облегчает отслеживание этих полезных изменений и их импорт.
2. Это облегчает возврат обратно, если вы когда-либо захотите (скажем, владелец оригинального проекта становится более охотно работать с вами).
3. Это облегчает отслеживание происхождения конкретного изменения, если вы когда-либо оглядываетесь на него, царапая голову, задаваясь вопросом, что это значит. В случае git это помогает вам искать ошибки из-за git bisect - вы можете найти изменение, которое, по вашему мнению, было безвредным, на самом деле критично. Это то, что можно легко найти с помощью bisect и очень сложно без него. Вы не можете этого сделать без истории.

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

Answer 5

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

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

Answer 6

Как указывали другие, вы должны действительно сохранить историю. Что касается README и управления версиями: вы должны переименовать свой проект, чтобы избежать путаницы с оригинальным проектом. Вы можете использовать имя, которое ссылается на исходный проект (но помните о потенциальных проблемах с товарными знаками), но старайтесь не быть неуважительным. Например, если вы назвали проект «foo-ng» (следующее поколение), если исходный проект называется «foo», то каким-то образом будет указано, что ваш проект «лучше», чем другой. Даже если вы чувствуете, что это так, не делайте этого.

README следует обновлять для ваших нужд. То есть он должен документировать название нового проекта, тот факт, что он является вилкой проекта «foo» и, возможно, точкой, в которой он разветвляется. Лично я бы также сохранил ChangeLogs и аналогичные, более технически ориентированные документы и при необходимости добавлял к ним, но приступал к новому документу «НОВОСТИ», то есть документу, предназначенному для конечных пользователей.

Answer 7

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

Другая интересная вещь о GitHub, в качестве дополнения к некоторым другим рабочего процесса отвечал ранее:

1. Создать аккаунт GitHub.
2. Вилок хранилища вы хотите (идя к своей странице на GitHub и нажав кнопку вилки)
3. Следуйте инструкции по git clone вашему новому репо локально
4. работы на вещах локально, как требуется; Кроме того, обязательно загрузите обновления из исходного источника на github (вы можете сделать это от к вашей версии проекта на github в очереди на вилку)
5. (Вместо отправки патча оригинальному автору) Задайте вопрос автор, чтобы захватить ваши патчи, перейдя на страницу очереди вил для оригинального проекта - это делает его безболезненным для оригинального автора, чтобы захватить ваши изменения.

Если вы получаете дрянные ответы от авторов проектов, то они точно не заслуживают вашей помощи, и вы не должны слишком беспокоиться о возвращении, я полагаю. Тем не менее, следуйте шагу 4 о вашей очереди вилок - вы можете оставаться в курсе всех остальных на github, которые вносят изменения в проект вместе с вами.

Быстрое добавление: если вы хотите, чтобы ваша работа немного отличалась от оригинальных авторов, это довольно легко: * Создайте новую ветку (git checkout -b my_branch_name) и работайте там.
* Если у вас есть ветка в нужном вам состоянии, вы можете вернуться к исходной ветке (git checkout master) и объединить свои изменения обратно (git merge my_branch_name).
* Затем вы можете нажать его обратно в github (git push origin master), или * Сделайте патч для оригинального автора (с некоторой версией git format-patch).