Oznacz Git jako „niekomfortowy”

41

Chcę pochwalić się niektórymi z moich prac, przesyłając je na moje konto GitHub. Istnieją jednak pliki zawierające hasła, na przykład połączenia z bazą danych.

Czy istnieje sposób oznaczenia pliku jako nieprzydatnego w Git, aby nie mógł pojawić się w GitHub?

Adam Carter
źródło
1
Sugestia styczna: może nie mieć zastosowania na każdej platformie, ponieważ niektóre są bardzo związane z plikami konfiguracyjnymi, ale można rozważyć zastosowanie 12-czynnikowego zachowania tych parametrów w środowisku: 12factor.net/config . Oznacza to, że kod aplikacji nigdy nie zakłada obecności pliku konfiguracyjnego. (W przeciwieństwie do prywatnego skryptu startowego, który je ustawia, ale nigdy nie opuszcza komputera lokalnego).
millimoose
1
Jeśli przypadkowo je zatwierdzisz, pamiętaj, aby usunąć je z historii w pełni git (inne pytania wyjaśnią, w jaki sposób), ponieważ nawet jeśli ją usuniesz i zignorujesz, stara zatwierdzona wersja pozostanie w historii i będzie widoczna na Github.
curiousdannii
3
Pamiętaj, że wszystkie odpowiedzi tak naprawdę nie odpowiadają na twoje pytanie. Nie powodują, że plik jest niekomfortowy, po prostu konfigurują git, aby domyślnie go ignorował. Ale jeśli przypadkowo wstawisz tę nazwę pliku do wiersza poleceń git, możesz w końcu ją zatwierdzić, nawet jeśli pasuje do wzorca .gitignore. AFAIK nie ma w 100% pełnego dowodu na to, gitaby uniknąć zatwierdzenia określonego pliku we wszystkich przypadkach. Chociaż może to być postrzegane jako funkcja ... pozwalająca na jawne polecenia zastępujące ogólne konfiguracje.
Bakuriu
Możesz usunąć zakodowane hasło i przejść do bezpieczniejszej alternatywy. Następnie możesz przełączyć hasła do bazy danych. Stare hasła nadal znajdują się w zatwierdzeniach, ale są nieaktualne, gdy ktoś w stanie je odczytać. Jestem prawie pewien, że nie możesz zmienić zatwierdzenia, gdy już jest oparte na nim.
BlueWizard
3
Oprócz tego, co powiedział @curiousdannii, GitHub ma całą stronę omawiającą sposób usunięcia poufnych danych, które przypadkowo popełniłeś. Ta strona mówi między innymi o zmianie haseł i kluczy, które przypadkowo opublikowałeś. help.github.com/articles/remove-sensitive-data
Kevin - Przywróć Monikę

Odpowiedzi:

67

Czy istnieje sposób oznaczenia pliku jako nieprzydatnego w Git, aby nie mógł pojawić się w GitHub?

Po pierwsze, nie ma sposobu, aby niektóre pliki i zatwierdzenia były widoczne w lokalnym repozytorium Git, ale w jakiś sposób nie były widoczne w GitHub; jeśli masz plik zatwierdzony w Git, pojawi się w GitHub.

Po drugie, nie ma prostego i praktycznego sposobu, aby oznaczyć sam plik jako „niepospolity”. Ale jest zdecydowanie sposób na zignorowanie pliku w repozytorium Git: Dodając plik (i) - w tym ich ścieżkę względną, jeśli potrzebne - do .gitignorepliku :

.gitignorePlik określa na zamierzone nieśledzone pliki Git powinny ignorować. Nie ma to wpływu na pliki już śledzone przez Git; szczegóły patrz UWAGI poniżej.

Utworzenie podstawowego .gitignorejest dość łatwe, ponieważ jest to zwykły plik tekstowy. Więc - na przykład - gdybym miał config.phpplik w twoim katalogu głównym, zrobiłbyś to; zakładając, że używasz PHP, ale koncepcja ma zastosowanie do każdej konfiguracji. Używam również Nano jako mojego edytora tekstu w tym przykładzie, ale możesz użyć dowolnego edytora tekstu, którego normalnie używasz do tego:

nano .gitignore

I po prostu dodaj tę nazwę pliku do tego pliku:

config.php

Zapisz go, a teraz Git po prostu zignoruje ten plik.

To powiedziawszy, co lubię robić dla takich konfiguracji, to pozostawienie konfiguracji repozytorium próbki / przykładu neutralnej wrażliwej specyfiki w repozytorium, więc mam pewne odniesienie do tego, jaki format pliku konfiguracyjnego to plik o nazwie coś takiego:

config.SAMPLE.php

W ten sposób wiesz dokładnie, jak config.phpplik powinien zostać skonfigurowany config.SAMPLE.phpi możesz upewnić się, że config.phpGit nigdy nie dotknie faktycznego .

Ponadto, jeśli planujesz pochwalić się swoim kodem, musisz spodziewać się, że ktoś spróbuje go pobrać i w jakiś sposób zaimplementować w swoim systemie. Pamiętaj, że nie jesteśmy tobą i bez przykładowego pliku konfiguracyjnego w repozytorium ludzie naprawdę nie zrozumieją, jak samodzielnie wdrożyć kod. Cholera, mogą nawet myśleć, że nie jesteś kompetentny, ponieważ nie podałeś podstawowego przykładu konfiguracji.

JakeGould
źródło
11
+1 za poprawną odpowiedź i sugerowanie przykładowego pliku konfiguracyjnego. Istnieje kilka bibliotek, takich jak Figaro dla Ruby, które popychają cię w tym kierunku. Powinieneś mieć plik przykładowy zatwierdzony o wartościach podobnych do wartości rzeczywistych, aby osoba, która patrzy na twój kod, wiedziała, jak powinno wyglądać środowisko. Niektóre platformy, takie jak Heroku, używają zmiennych środowiskowych, więc możesz ustawić konfigurację na coś takiego database_url = Environment.DATABASE_URLi pozostawić komentarz powyżej # postgres://username:password@localhost/dbname.
Chris Cirefice,
@ChrisCirefice Dzięki! Zawsze mnie zadziwia, że ​​pojawiają się nowe „narzędzia”, które powinny przypominać o oczywistości: jeśli ten kod będzie czytany przez innych ludzi, nie wyjaśnienie, jak działa konfiguracja, co dokładnie robi? Dzięki jeszcze raz.
JakeGould,
27

Możesz także dodać hak poprzedzający zatwierdzenie, aby zaimplementować kontrolę poczytalności. Katalog .git/hookskażdego repozytorium git zawiera kilka przykładowych skryptów.

Wywołany skrypt pre-commitjest wykonywany, jeśli istnieje przed każdym zatwierdzeniem, a niezerowa wartość zwrotna przerywa zatwierdzenie.

Na przykład możesz mieć taki prosty skrypt:

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

A jeśli to filenamepasuje, zatwierdzenie nie powiedzie się.

Juho Östman
źródło
1
+1 to właściwa odpowiedź, która faktycznie uniemożliwia jawne dodawanie i zatwierdzanie pliku.
R ..
Rzeczywiście, chociaż zalecaną praktyką nie jest poleganie na stosowaniu tego zapobiegania (tj. Zamiast tego należy użyć `.gitignore).
David Z
2
@R .. Tak i nie. Podczas gdy pytanie brzmi: „oznaczenie pliku jako niepomyślnego”, duch „uniemożliwia popełnienie pliku”. Rzeczywistość, którą tworzy, .gitignorejest bardzo powszechną - i powszechnie rozumianą - praktyką dla każdego, kto używa Git. Ale skrypt przed zatwierdzeniem nie jest tak naprawdę używany przez większość użytkowników Git. Wymaga pewnej wiedzy na temat instalacji i prawdziwego powodu, dla którego taka metoda byłaby lepsza niż zwykłe użycie .gitignorepliku. Jest to jednak bardzo przydatne w niektórych bardziej skomplikowanych przypadkach, ale z pewnością jest to koncepcja, którą można zastosować, gdy naprawdę wiesz, że musisz go użyć.
JakeGould
2
Widziałem użycie tego w sytuacjach, w których możesz nie ufać w 100% .gitignore (możesz zrobić coś głupiego, przypadkowo żądając, aby git dodał plik do zatwierdzenia). A może ktoś inny może edytować plik .gitignore (w końcu jest pod kontrolą wersji). Jeśli naprawdę potrzebujesz procesu, który można przetestować, możesz nad tym popracować.
Cort Ammon
@CortAmmon nie zawsze chodzi o zaufanie. Do kodu źródłowego możesz dodać tymczasowe i niepubliczne informacje debugowania, których nie chcesz zatwierdzać, ale nie możesz zignorować takiego pliku. Zamiast tego chcesz to sprawdzić przed zatwierdzeniem, jeśli nie zawiera niczego nielegalnego . To wygląda na dobre rozwiązanie dla tego przypadku użycia. I tak w zasadzie tak znalazłem to pytanie, ponieważ jest to mój przypadek użycia.
t3chb0t
12

Co powiedział @JakeGould. W niektórych przypadkach można również użyć specjalnych bitów pliku, takich jak skip-worktreelub, assume-unchangedktóre można ustawić w następujący sposób; różnice między nimi znajdują się w odpowiedzi na Przepełnienie stosu :

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

Który następnie ukryje dodatkowe zmiany w już istniejącym pliku i którego możesz użyć, jeśli naprawdę chcesz, aby plik był tam po każdym ściągnięciu. Ale radziłbym ci go używać tylko wtedy, gdy naprawdę wiesz, co robisz.

phk
źródło
8

Użyj .gitignorepodobnego @JakeGould powiedział. Ponadto niektóre powiązane informacje:

  • .gitignorechroni pliki przed śledzeniem; jeśli są już śledzone, użyj ich git rm --cacheddo usunięcia
  • pliki / wzorce w $GIT_DIR/info/excluderównież zostaną zignorowane
  • pliki / wzorce w pliku określonym przez core.excludesFile użytkownika ~/.gitconfigrównież są ignorowane.

Więcej informacji znajduje się w oficjalnej dokumentacji Git .

46 i 2
źródło
2

Aby rozszerzyć odpowiedzi Jake'a i 46: jedną bardzo dobrą praktyką jest posiadanie spójnego rozszerzenia, którego używasz dla plików, w których umieszczasz prywatne informacje, i .gitignorezawsze używaj globalnego wykluczania plików z tym rozszerzeniem (używając .gitconfigpliku wymienionego gdzie indziej, aby zawsze był ignorowany dla użytkownika).

W ten sposób możesz na przykład:

/projectname/mypasswords.exc 

a jeśli zostałeś wykluczony *.excglobalnie, wiesz, że nie zostanie on popełniony, nawet jeśli zapomnisz indywidualnie wykluczyć ten konkretny plik.

Joe
źródło