Mam taki mały problem. Firma powoli przechodzi niektórymi projektami na #git z svn. Ktoś sobie wymyślił, żeby na repo gita wrzucić cały projekt, żeby nowi mieli od razu dobry start - źródła, biblioteki, ustawienia projektów. I to jest niby ok na start, tylko że na branchu develop/main nie wszyscy powinni pracować. Zaczynam się więc bawić w branche własne. Teoretycznie ogarniam merge / rebase powoli, ale mam problem z plikami właśnie projektów, ustawień - nie chcę ich commitować, a z racji specyfikacji pracy, będę mieć tam mocne różnice względem mastera.
Ogólnie problem pojawił się przy pull, jak chcę mojego brancha podciągnąć pod mastera - i merge i rebase się rzucają, że mam niezacommitowane pliki i zostaną zniszczone.
Czego próbowałem: - dodać do gitgnore - dodać do skip-work-tree - rm --cached plikustawien.xml - wrzucić do stasha (niby to pozwala zrobić merge, ale nie działa potem pop ze stasha, bo konflikty).
Cały czas są w oczekujących commitach, albo po "rm --cached" chce je wysłać jako "deleted" (a tego chyba nie mogę zrobić, bo push wytnie te pliki pozostałym(?). Co robię źle? Rozumiem, że te pliki nie do końca powinny być wersjonowane u mnie, ale masterze zawsze będą. Jak to pieroństwo (pliki własnych ustawień) wyłączyć z obsługi jak już się poinstalowałem i mam własne "środowisko"?
@RRybak: wut? Których plików nie chcesz wersjonować? To co powinieneś użyć to właśnie .gitignore tylko pamiętaj, że jak coś raz dodałeś do git-a to .gitignore nie zadziała, musisz sobie z gita wycofać ten plik i wtedy będzie ignorowany. Dobrą praktyką jest dodanie do git-a przykładowej konfiguracji i jeżeli trzymasz główne config-i w pliku .env to dodać drugi, np. .env.default, w którym będziesz miał pokazane jakich zmiennych wymaga projekt. Wtedy
@ajgoron: nadal mam wątpliwości. To jest w teorii wszystko co próbuję właśnie zrobić: Problem w tym, że ten plik był już wersjonowany, bo do mnie wjechał, tak? Teraz próbuję zarówno: - git reset plikkonfiguracji.xml (oznacza się jako śledzony, nie do złożenia - nadal blokuje pulle) - git rm --cached plikkonfiguracji.xml (oznacza się jako "usunięto, do złożenia w commicie")
I właśnie z tym ostatnim punktem mam zagwózdkę - czy to jest commit do mojego indexu,
@RRybak: nie no, kurna nie działa. Po wszystkich zabawach z git restore przywraca mi jakieś wersje z ostatnich "zacofanych" commitów, i muszę wszystkie biblioteki na nowo ustawiać. Ja chcę po prostu mieć swoje zmiany i odczepić gita od tego miejsca. Sprawy nie ułatwia fakt, że odnoszę wrażenie że git z CLI pokazuje mi coś innego niż klikalny git z netbeansa (to co niby git ignoruje netbeans próbuje commitowac)
@RRybak: doczytalem teraz, ze tez ustawienia projektow chcecie trzymac w repo. Ale to nie tak sie je trzyma. Powinniscie utworzyc osobne repozytorium na GH do konfiguracji IDE pod projekt. Nowoczesne IDE pozwalaja wspoldzielic taka konfiguracje, zwykle ustawia sie to w opcjach. Poczytaj o tym. Wrzucanie tego tak jak teraz robisz to blad i prowadzi do utrudnien w pracy.
@RRybak: docker compose dla wspólnej konfiguracji projektu na czas developmentu a co do gita to może by zastosować metodologię git flow? Widzę że lubia sobie u ciebie utrudniać życie xd
Teoretycznie ogarniam merge / rebase powoli, ale mam problem z plikami właśnie projektów, ustawień - nie chcę ich commitować, a z racji specyfikacji pracy, będę mieć tam mocne różnice względem mastera.
Ogólnie problem pojawił się przy pull, jak chcę mojego brancha podciągnąć pod mastera - i merge i rebase się rzucają, że mam niezacommitowane pliki i zostaną zniszczone.
Czego próbowałem:
- dodać do gitgnore
- dodać do skip-work-tree
- rm --cached plikustawien.xml
- wrzucić do stasha (niby to pozwala zrobić merge, ale nie działa potem pop ze stasha, bo konflikty).
Cały czas są w oczekujących commitach, albo po "rm --cached" chce je wysłać jako "deleted" (a tego chyba nie mogę zrobić, bo push wytnie te pliki pozostałym(?).
Co robię źle? Rozumiem, że te pliki nie do końca powinny być wersjonowane u mnie, ale masterze zawsze będą. Jak to pieroństwo (pliki własnych ustawień) wyłączyć z obsługi jak już się poinstalowałem i mam własne "środowisko"?
#programowanie
.gitignoretylko pamiętaj, że jak coś raz dodałeś do git-a to.gitignorenie zadziała, musisz sobie z gita wycofać ten plik i wtedy będzie ignorowany. Dobrą praktyką jest dodanie do git-a przykładowej konfiguracji i jeżeli trzymasz główne config-i w pliku.envto dodać drugi, np..env.default, w którym będziesz miał pokazane jakich zmiennych wymaga projekt. WtedyEDIT: źle przeczytałem xD
Problem w tym, że ten plik był już wersjonowany, bo do mnie wjechał, tak? Teraz próbuję zarówno:
- git reset plikkonfiguracji.xml (oznacza się jako śledzony, nie do złożenia - nadal blokuje pulle)
- git rm --cached plikkonfiguracji.xml (oznacza się jako "usunięto, do złożenia w commicie")
I właśnie z tym ostatnim punktem mam zagwózdkę - czy to jest commit do mojego indexu,
.gitignoreuzyj prostego skryptu bash:https://pastebin.com/g5FXrBGN
Sprawy nie ułatwia fakt, że odnoszę wrażenie że git z CLI pokazuje mi coś innego niż klikalny git z netbeansa (to co niby git ignoruje netbeans próbuje commitowac)
edit: nie
echo plikkonfiguracji.xml >> .git/info/excludelub stwórz sobie globalne gitignore w~/.config/git/ignorei tam dodaj tę ścieżkę.