Нужно делать fork или clone?

Из переписки (16.04.21 14:01):

Хочу уточнить про систему взаимодействия при работе над семестровым проектом. Мы хотим использовать схему pull. Получается нам надо всем сделать fork общего репозитория, каждый в своей копии делает свою часть работы, потом посылает pull request к главному, который мержит изменения в общий репозиторий, после чего все делают pull и все по новой? Или все должны клонировать общий репозиторий с помощью git clone и работать в локальном репозитории, отправляя потом патчи тому, кто мержит? Более конкретно вопрос, который меня интересует: нужно делать fork или clone? Не будет ли конфликтов при попытке смержить, если был сделан fork(это же копия репозитория, а не сам репозиторий) и сохранится ли при мерже информация об авторе коммитов(если сохраняется, то при каком из вариантов действий)?

• > fork или clone?

Это одно и то же. Вот ман по git clone (https://git-scm.com/docs/git-clone). А мана по git fork нету)

Короче, IRL всё просто до изумления. У каждого участника процесса есть публичный репозиторий, куда он публикует результаты своей работы. Общий проект — это группа таких репозиториев, обладающая общей историей.

Т. е. кто-то (не обязательно он будет потом главным), публикует первый репозторий. В какой-то момент (необязательно сразу) к проекту присоединяется ещё участник. Он клонирует исходный репозиторий и публикует его как свой публичный. Факт такой публикации и есть «fork», этот термин нестрогий. Типичная практика: создать пустой репозиторий, запуллить все коммиты из исходного (пустой репозиторий по определению имеет общую историю с любым), запушить.

Всё.

Теперь касаемо практики совместной работы

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

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

Далее по кругу

Подробности:

Чтобы иметь возможность постоянно работать над проектом, для такой доделки удобно заводить новую ветку, совпадающую с precious source, перекладывать туда уже имеющиеся изменения (лучше rebase-ить, история будет понятнее), доделывать, что не успел, и см. выше: уведомляем Линуса, что доделка готова, указываем ветку.

Ну, если у нас «играющий тренер», т. е. «пишущий Линус», т. е. ревьюер проекта, который сам тоже пишет, он просто делает всю свою работу в отдельной ветке (отдельный публичный репозиторий обычно оверкилл), и дальше играет по тем же правилам. Только уведомлять себя не обязан, но, кстати, нередко это делается: например, если уведомления идут через список рассылки, то их читают все члены команды, так что слать уведомления самому себе — хороший тон.

Есть ещё олдскульный вариант, в котором обязательна публикация только precious source репозитория. Это схема с git-send-email/git-am. В ней уведомление (почтовое) одновременно является и носителем всех коммитов. Но если присмотреться, она ничем не отличается от описанного выше, она даже проще. Ничего публиковать не надо никому, кроме Линуса, вся история разработки в одном списке рассылки и т. п.

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