Вопрос по gitignore, git, github – git: иметь разные файлы .gitignore для каждого пульта

59

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

Есть ли какой-нибудь способ иметь разные файлы .gitignore, по одному на каждый пульт?

@opensas, я прошел через вашу библиотеку openshift play 2 и наткнулся на ту же проблему: как поддерживать нормальное git-репо для разработки (исключая все сгенерированные файлы) и одно явно для развертывания (содержащее все сгенерированные файлы). Вы нашли хорошее решение до сих пор? Bachi
Bachi: в конце концов я просто написал небольшой скрипт на bach, который просто копирует приложение while в другой каталог и запускает openshift_deploy оттуда. То есть я храню два совершенно разных репозитория git. Я мог бы сделать это с помощью веток и разных .gitignore для каждой ветки, но я думаю, что этот подход чище. Кроме того, перед развертыванием легче обрабатывать / минимизировать js-файлы. opensas
упс, только что нашел этот вопрос:stackoverflow.com/questions/2456533/… opensas
@opensas Извините, что поднял здесь невероятно старую тему, но как бы вы использовали разные файлы .gitignore для каждой ветви? Я пытаюсь понять это сам ... Swivel

Ваш Ответ

4   ответа
36

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

Это можно сделать с помощью схемы ветвления, где у вас есть «развертывание». ветвь, которая отделяется от master и является такой же, но содержит дополнительные скомпилированные файлы. Это может быть даже автоматизировано с помощью git-хуков, чтобы автоматически компилировать файлы и добавлять их в репозиторий. Я предполагаю такую структуру:

master:       A ---> B ---> C ---> D
               \      \      \      \
                \      \      \      \
deployment:      -> A'  -> B'  -> C'  -> D'

то есть каждый раз, когда определенный сервер получает новый коммит на master, он строит проект, добавляет созданные файлы в новый коммит из D и фиксирует это в ветке развертывания, которую затем не нужно отправлять в github.

хорошая идея, я не думал о том, чтобы использовать разные ветви, каждая со своей собственной .gitignore opensas
1

подмодули git.

Это может быть полезно, если, например, вы хотите, чтобы ваш код и документация были в двух разных репозиториях с независимым контролем доступа и т. Д. Таким образом, у вас будет 3 репо, субмодульное репо для документов, другое для кода и & quot ; мастер & Quot; (не подмодуль git) репо, содержащее оба (возможно, для загрузки pypi). Это достойный способ организовать учебник по КС. Оба проекта могут продвигаться вперед независимо друг от друга и синхронизироваться в основных выпусках, управляемых главным специалистом по репо.

2

В моем случае мне нужно было синхронизировать проект с heroku и github (в качестве публичного репо).

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

Обычно простой проект имеет следующую структуру папок

Project folder (remote heroku)
    - .git
    - .gitignore
    - (folders and files)

Я добавил еще один уровень и создал еще один git-репозиторий с gitignore, который пропустил бы некоторые файлы из моего проекта.

Project public (remote github)
    - .git
    - .gitignore
    - Project folder (remote heroku)
        - .git
        - .gitignore
        - (folders and files)

Так что это не git-репозиторий с двумя удаленными репозиториями с разными gitignores.

Есть два разных хранилища.

На самом деле я исключаю только файлы, сгенерированные IDE, и некоторые файлы, сгенерированные во время выполнения.

На внешнем уровне я исключаю все файлы, которые нельзя обнародовать.

1

automated solution к методам, упомянутым здесь:

ed differently Init new git within the subfolder(s) and assign the remote configuration Modify the root folder's .git/hooks/pre-push file to exec git push at those sub folders based on the incoming arguments.
Я закончил тем, что делал это самостоятельно. Если вы действительно хотели автоматизации. сделать эту папку временной папкой и удалитьcd ..; rm -rf temp_folder; после нажатияgithub.com/MichaelDimmitt/publicize_readme/blob/master/… github.com/MichaelDimmitt/publicize_readme/blob/master/…

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