Если у вас есть один репозиторий, в котором части должны быть общедоступными, а части - частными, то вам необходимо что-то кардинально изменить в настройках своего репозитория. git отслеживает полные репозитории, так что вы можете сделать репозиторий общедоступным или закрытым, но не частично это, а частично это.
Если у вас есть как репозиторий с «общедоступными» файлами, так и репо с «приватными» файлами, вы можете добавить ловушку git к «общедоступному» репо, чтобы автоматически выдавать коммиты, и просто сохранять частный репозиторий закрытым.
Однако вы пишете, что у вас есть один репозиторий, содержащий как «публичные», так и «приватные» файлы, поэтому вам нужно разделить это на что-то «публичное» и что-то «приватное» каким-то образом.
У вас есть несколько вариантов решения этой ситуации:
Разделите папку "public" в свой собственный репозиторий, который вы
подтолкнет к github. Это немного переписает историю «публичной» папки.
Я изложу это более подробно ниже.
Создать ветку, которая касается только «публичной» папки,
и только опубликовать эту ветку.
Это рискованно в смысле «случайно толкать, то есть публиковать, личные вещи»,
и совершенно невозможно или, по крайней мере, довольно сложно сделать, если у вас есть
любые коммиты, которые касаются как «публичных», так и «приватных» файлов, поэтому я бы
советую против этого варианта, и не буду больше об этом писать.
Для разбиения «публичной» папки на собственный репозиторий создайте новую «публичную» ветку из вашей «комбинированной» ветки и используйте git filter-branch, чтобы сделать новую «общедоступную». В ветке содержатся только вещи из «публичной» папки. В разделе «Примеры» показан только правильный пример --subdirectory-filter). Тогда у вас будет старая ветвь «с комбинированием» с папкой «public» и личным содержимым в ней, а также новая ветка «public» только с папкой «public».
Имейте в виду, что, например, Сообщения коммита в новой «публичной» ветке все еще могут содержать «приватную» информацию. Поэтому вы должны просмотреть все сообщения о коммитах, отсканировать их на предмет личной информации и, возможно, отредактировать эту личную информацию, например, с git rebase -i.
Обновление: [Последующее нажатие только на "открытую" ветвь и ничто иное, вероятно, не передаст никакой другой информации, поэтому такая очистка репо, вероятно, не требуется.] Если вам нужно было делать какие-либо изменения, вы захотите удалить старые неотредактированные обороты из репозитория, используя git gc (возможно, с опциями --prune=0 и --aggressive - но я не могу найти SO ответьте с дополнительной информацией об этом).
Теперь ваша "публичная" ветка готова к публикации. Чтобы убедиться, что она содержит только «общедоступную» информацию, вы можете вставить ее в новый пустой локальный репозиторий, проверить его содержимое и убедиться, что все ссылки не имеют личной информации. После того, как вы удовлетворены, вы можете перенести ветку "public" в новое пустое хранилище на github. В этом случае репозиторий на github будет содержать ТОЛЬКО ветку public, которую вы, вероятно, должны назвать «master» в репозитории github.
Ваше локальное репо с «объединенной» ветвью по-прежнему содержит как общедоступную, так и личную информацию напрямую, и не имеет никакого отношения к новому «общедоступному» репозиторию github.
Теперь вы могли бы переписать историю "объединенной" ветки, чтобы она просто содержала непубличные биты, но это принесло бы в жертву все связи между состоянием "публичных" и "приватных" файлов во время всех история, поэтому повторяющиеся сборки старого материала станут почти невозможными. Поэтому я предлагаю оставить историю «объединенной» ветки в покое и просто удалить из нее «публичную» папку в новом коммите.
Если интеграция между вашими личными и общедоступными файлами очень тесная и зависит от версии, вы можете использовать git submodule, чтобы добавить определенную версию «публичного» репо из github в ваше личное репо. Новая папка субмодулей, названная так же, как и прежняя «публичная» папка, сведет к минимуму изменения в ваших личных материалах, так как тогда все «публичные» файлы будут иметь свой старый путь. Обратите внимание, что папка субмодуля не будет обновляться автоматически, когда что-то было перенесено в github. Вы можете обойти это, добавив git hook в вашу локальную папку субмодуля, которая обновит информацию о субмодуле в «комбинированном» репо.
Если интеграция между вашими личными и общедоступными файлами более свободна, вы также можете обращаться с общедоступными файлами как с любым внешним сторонним проектом и интегрировать их в свои личные файлы так, как это сделал бы кто-либо другой, т.е. внешняя часть программного обеспечения, от которой зависит ваше «частное» программное обеспечение.