Позначте файл як "незручний" за допомогою Git


41

Я хочу показати свою роботу, завантаживши їх у мій обліковий запис GitHub. Однак є деякі файли, що містять паролі, як-от підключення до бази даних.

Чи є спосіб позначати файл непридатним із Git, щоб він не міг з’являтися на GitHub?


1
Тангенціальна пропозиція: Це може застосовуватися не на кожній платформі, оскільки деякі з них дуже одружені з файлами конфігурації, але ви можете розглянути наступний підхід 12factor щодо збереження цих параметрів у середовищі: 12factor.net/config . Тобто, якщо прикладний код ніколи не припускає наявність конфігураційного файла. (На відміну від приватного сценарію запуску, який встановлює їх, але ніколи не залишає локальну машину.)
millimoose

1
Якщо ви випадково скористаєтеся ними, переконайтесь, що ви вилучили їх із історії повністю git (інші питання пояснять, як), тому що навіть якщо ви видалите та проігноруєте її, стара надана версія залишиться в історії та буде видно на Github.
курйозданні

3
Зауважте, що всі відповіді насправді не відповідають на ваше запитання. Вони не роблять файл незручним, вони просто налаштовують git так, що він ігнорує його за замовчуванням. Але якщо ви випадково вставите це ім'я файлу в командний рядок git, ви можете в остаточному підсумку зробити його, навіть якщо воно відповідає шаблону в .gitignore. AFAIK не існує 100% повного підтвердження способу повідомлення, gitщоб уникнути компіляції певного файлу у всіх випадках. Хоча це може розглядатися як особливість ... дозволяє чіткими командами змінювати загальні конфігурації.
Бакуріу

Ви можете видалити жорсткі коди паролів і перейти на більш безпечну альтернативу. Після цього ви можете переключити паролі бази даних. Старі паролі все ще знаходяться всередині комітетів, але вони застаріли, коли хтось може, ніж ви, зможе їх прочитати. Я майже впевнений, що ви не можете змінити зобов’язання, як тільки це вже будується.
BlueWizard

3
Окрім того, що сказав @curiousdannii, у GitHub є ціла сторінка, на якій обговорюється, як видалити конфіденційні дані, які ви випадково вчинили. Крім цього, на цій сторінці написано, щоб змінити паролі та ключі, які ви випадково опублікували. help.github.com/articles/remove-sensitive-data
Кевін -

Відповіді:


67

Чи є спосіб позначати файл непридатним із Git, щоб він не міг з’являтися на GitHub?

По-перше, у вашому локальному сховищі Git неможливо побачити деякі файли і коміти, але якимось чином не можна побачити в GitHub; якщо у вас є файл, скоєний у Git, він з’явиться в GitHub.

По-друге, немає простого і практичного способу позначити окремий файл як "незручний". Але, безумовно, існує спосіб ігнорувати файл у репортажі Git: Додаючи файли (файли) - включаючи їх відносний шлях, якщо потрібно - до .gitignoreфайлу :

.gitignoreФайл визначає навмисно неотслежіваемих файли, Git повинні ігнорувати. Файли, які вже відстежуються Git, не впливають; див. ПРИМІТКИ нижче для отримання детальної інформації.

Створити базовий .gitignoreдосить просто, оскільки це просто звичайний текстовий файл. Так, наприклад, якби я мав config.phpфайл у вашому корені, ви зробите це; припустимо, що ви використовуєте PHP, але ця концепція застосовується для будь-якої установки. Також у цьому прикладі я використовую Nano як свій текстовий редактор, але не соромтесь використовувати будь-який текстовий редактор, який ви зазвичай використовуєте для цього:

nano .gitignore

І просто додайте це ім'я до цього файлу:

config.php

Збережіть це, і тепер Git просто ігнорує цей файл.

Слід сказати, що я люблю робити для таких установок, як зберігати зразок / приклад конфігурації нейтралізованих чутливих специфік у сховищі, тому я маю деяку посилання на те, який формат конфігураційного файлу - це файл із таким ім'ям:

config.SAMPLE.php

Таким чином ви точно знаєте, як config.phpслід налаштувати файл, config.SAMPLE.phpі ви можете переконатися, що config.phpGit фактично ніколи не торкається.

Крім того, якщо ви плануєте демонструвати свій код, вам потрібно розраховувати, що хтось спробує взяти цей код і якось реалізувати його у своїй системі. Пам'ятайте, що ми не ви та без зразкового конфігураційного файлу у вашому репо, люди насправді не зрозуміють, як реалізувати код самостійно. Чорт забирають, що вони можуть здатися вам непрацездатними, оскільки ви не навели базовий приклад конфігурації.


11
+1 для правильної відповіді та пропозиції примірного файлу конфігурації. Є такі бібліотеки, як Figaro для Ruby, які наштовхують вас у цьому напрямку. У вас повинен бути зразок файлу, який має значення, подібні до реальних, щоб людина, яка дивиться на ваш код, знала, як має виглядати середовище. Деякі платформи, як-от Heroku, використовують змінні середовища, тож ви можете встановити свою конфігурацію на щось таке, як database_url = Environment.DATABASE_URLі залишити коментар, як-от вище # postgres://username:password@localhost/dbname.
Chris Cirefice

@ChrisCirefice Дякую! Завжди дивує мене, що з'являються нові "інструменти", які повинні нагадувати вам про очевидне: якщо цей код читатимуть інші люди, не пояснюючи, як саме працює конфігурація? Знову дякую.
JakeGould

27

Ви також можете додати гачок, який попередньо здійснює, щоб здійснити перевірку правильності. У каталозі .git/hooksкожного сховища git є кілька прикладних скриптів.

Викликаний скрипт pre-commitвиконується, якщо він існує перед кожним фіксацією, а ненульове значення повернення перериває комісію.

Наприклад, у вас може бути такий простий скрипт:

#! /bin/sh -e
git ls-files --cached | grep -qx 'filename' && { echo "Excluded file included in the commit" >&2; exit 1; }
exit 0

І якщо це filenameзбігається, комісія провалюється.


1
+1 - це правильна відповідь, яка фактично перешкоджає явному додаванню та виконанню файлу.
Р ..

Дійсно, хоча рекомендована практика не покладатися на те, щоб ця профілактика була встановлена ​​(тобто використовувати замість `.gitignore).
David Z

2
@R .. Так і ні. Хоча в питанні йдеться про те, що "позначаючи файл як непридатний", дух "запобігає виконанню файлу". Реальність створює .gitignoreдуже поширену практику для тих, хто використовує Git. Але сценарій перед фіксацією насправді не використовується більшості користувачів Git. Це вимагає певних знань про налаштування, і це потрібна справжня причина, чому такий метод, як цей, було б кращим, ніж просто використовувати .gitignoreфайл. Але це дуже корисно для деяких більш складних випадків, але це, безумовно, концепція, яку ви використовували б, коли справді знаєте, що потрібно її використовувати.
JakeGould

2
Я можу побачити використання цього в ситуаціях, коли ви можете не на 100% довірити .gitignore (ви можете зробити щось нерозумне, випадково вимагаючи git додати файл для виступу). Або, можливо, хтось інший може відредагувати файл .gitignore (зрештою, він знаходиться під контролем версій). Якщо вам справді потрібен тестований процес, це щось, що ви могли б працювати в такому процесі.
Корт Аммон

@CortAmmon справа не завжди в довірі. Ви можете додати деяку тимчасову та непублічну інформацію про налагодження до свого вихідного коду, яку ви не хочете робити, але не можете ігнорувати такий файл. Натомість ви хочете перевірити це перед тим, як вступити в дію, чи не містить він нічого незаконного . Це виглядає як вдале рішення для цього випадку використання. І як факт, саме так я знайшов це питання, оскільки це мій випадок використання.
t3chb0t

12

Що сказав @JakeGould У деяких випадках ви також можете використовувати спеціальні біти файлів, наприклад, skip-worktreeабо assume-unchangedякі можна встановити наступним чином; про відмінності між ними див. цю відповідь на переповнення стека :

git update-index --assume-unchanged <file>

Потім приховатимуть додаткові зміни до вже наявного файлу і які ви можете використати, якщо дійсно хочете, щоб файл був там після кожного витягування. Але я б радив використовувати його лише тоді, коли ви дійсно знаєте, що робите.


8

Використовуйте так, .gitignoreяк сказав @JakeGould. Крім того, деякі пов’язані відомості:

  • .gitignoreзапобігає відстеженню файлів; якщо вони вже відстежуються, використовуйте git rm --cachedдля їх видалення
  • Файли / шаблони в $GIT_DIR/info/excludeтакож будуть ігноровані
  • Файли / шаблони у файлі, визначені core.excludesFile у користувачеві, ~/.gitconfigтакож ігноруються.

Детальну інформацію див. В офіційній Git-документації .


2

Щоб поширитись на відповіді Джейка та 46: одна дуже хороша практика - це послідовне розширення, яке ви використовуєте для файлів, до яких є приватна інформація, і використовувати .gitignoreзавжди виключення файлів із цим розширенням у всьому світі (використовуючи .gitconfigфайл, як згадувалося в іншому місці, щоб завжди його ігнорувати для вашого користувача).

Таким чином, ви можете мати, наприклад:

/projectname/mypasswords.exc 

і якщо ви виключили *.excглобально, то ви знаєте, що це не буде скоєно, навіть якщо ви забудете окремо виключити цей конкретний файл.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.