Widziałem stronę wiki na GitHub, która nie jest otwarta do edycji. Następnie rozwidliłem projekt, zredagowałem go „po mojej stronie” i spróbowałem wykonać pull request. Okazuje się, że wiki nie ma w projekcie i nie ma sposobu na wprowadzenie zmian.

Czy istnieje inny sposób niż wysyłanie e-maili, jeśli chcę zasugerować zmianę na wiki w tym przypadku?

^{W tym momencie dowiedziałem się, co wydaje się alternatywą w sekcji „Pytania o podobnych tytułach”, ale nie mogłem jeszcze wykonać z nim żądania ściągnięcia, więc nie jestem pewien, czy podmoduły są dobrym sposobem do tego celu. Teraz widzę, że prawdopodobnie mógłbym to jakoś rozgałęzić ... Więc czy to jest droga?}

GitHub nie obsługuje żądań ściągnięcia dla repozytorium wiki , tylko główne repozytorium (to trochę wstyd, IMO, ale mogę to zrozumieć).

Oto interesujący sposób, w jaki jeden projekt zarządza aktualizacjami społeczności na swojej wiki, jednocześnie zachowując ścisłą kontrolę, jeśli chodzi o kod źródłowy:

Mój proponowany przepływ pracy jest następujący:

1. Ręcznie utwórz rozwidlenie wiki Taffy na swoim koncie Github:
   • Utwórz nowe repozytorium na swoim koncie github. Nazwijmy to „Taffy-Wiki”.
   • Sklonuj repozytorium wiki Taffy na swój lokalny komputer: git clone git@github.com:atuttle/Taffy.wiki.git
   • Usuń oryginalny „pochodzenie” Remote i dodaj swoją GitHub repo jako nowego „pochodzenie” git remote rm originorazgit remote add origin git@github.com:<YOUR_USERNAME>/Taffy-Wiki.git
2. Wprowadź proponowane zmiany lokalnie, a następnie prześlij je na swoje konto github: git push -u origin master('-u origin master' wymagane tylko za pierwszym razem; potem po prostu zróbgit push )
3. Prześlij zgłoszenie do oficjalnego modułu śledzenia problemów Taffy z prośbą o przejrzenie zmian i ich scalenie. Pamiętaj, aby dołączyć link do swojego repozytorium i opisać, co zmieniłeś.
4. Idź do # 2

(Z Jak możesz przyczynić się do dokumentacji Taffy .)

Gdybym to był ja, utworzyłbym problem w głównym repozytorium (to znaczy tym, który rozwidliłeś) sugerując aktualizację wiki. Jeśli problemy nie są włączone, to e-mail to jedyna inna opcja, o której przychodzi mi do głowy.

Przyjąłem inne podejście, polegające na umieszczeniu dokładnie tej samej zawartości zarówno w głównym repozytorium, jak i na wiki. To nie przypadnie do gustu każdemu, ale Risk-First to głównie wiki z kilkoma stronami Jekyll w głównym repozytorium.

Oznacza to, że proces żądania ściągnięcia / rozwidlenia działa poprawnie. Jednak po scaleniu żądania ściągnięcia muszę wykonać dodatkowy krok polegający na ściągnięciu do mojego lokalnego repozytorium, a następnie wypchnięciu zarówno do głównego repozytorium, jak i wiki, które git obsługuje dobrze z wieloma źródłowymi adresami URL:

localhost:website robmoffat$ git remote show origin
* remote origin
  Fetch URL: git@github.com:risk-first/website.git
  Push  URL: git@github.com:risk-first/website.wiki.git
  Push  URL: git@github.com:risk-first/website.git
  HEAD branch: master

Aby to osiągnąć, połączyłem commity z obu repozytoriów, wykonując następujące czynności:

Jak połączyć dwa repozytoria Git?

Następnie push do obu repozytoriów w ten sposób:

Git - wysyłanie kodu do dwóch pilotów

Mam nadzieję, że to komuś pomoże.

Jak dotąd najlepsze rozwiązanie problemu znaleźliśmy w witrynie https://devonfw.com :

1. Umieść swoją dokumentację w repozytorium git wraz z kodem w folderze dokumentacji.
2. Rozszerz swoją kompilację Travis-ci o magię, która przygotowuje wszystkie zmiany z tego folderu dokumentacji z transformacjami zastosowanymi do wiki git. Zobacz ostatni przykładowy link poniżej.
3. Potraktuj wiki jako widok tylko do odczytu w dokumentacji. Pamiętaj, że dzięki github.com możesz nadal przeglądać i bezpośrednio edytować pliki w folderze dokumentacji. Więc nadal możesz naprawić literówki w przeglądarce w ciągu kilku sekund (nawet jako PR bez uprawnień do repozytorium) - tylko nie za pośrednictwem wiki.
4. Kiedy współautor się rozwidla, ma również dokumentację z kodem. Może zmienić oba w jednym PR i wszystkie są sprawdzane w tym samym procesie, więc po scaleniu kodu i dokumentu pozostaje zsynchronizowany. Nadal masz przyjemniejszy UX do czytania dokumentacji na wiki z paskiem bocznym itp.

Ponieważ jesteśmy w 100% OSS, uwielbiamy dzielić się naszymi ciężkimi wysiłkami, aby znaleźć to wspaniałe rozwiązanie. Oto przykładowe linki:

• https://devonfw.com/website/pages/docs/master-devon4j.asciidoc_introduction.html
• https://github.com/devonfw/devon4j/wiki/architecture
• https://github.com/devonfw/devon4j/blob/develop/documentation/architecture.asciidoc#architecture
• https://repo1.maven.org/maven2/com/devonfw/java/doc/devon4j-doc/3.2.0/devon4j-doc-3.2.0.pdf
• https://github.com/devonfw/devon4j/blob/develop/.travis.yml

Nie możesz wykonać żądania ściągnięcia, ale możesz otworzyć problem, wkleić łącze do swojej strony wiki i pozwolić im scalić swoją stronę wiki z ich stroną wiki.

W skrócie:

Muszą tylko sklonować repozytorium strony wiki, ( git clone YOUR_FORKED_REPO.wiki.git), zgnieść wszystkie zatwierdzenia wiki do jednego dużego zatwierdzenia, a następnie wybrać to duże zgniecione zatwierdzenie do ich repozytorium. Spowoduje to wprowadzenie wszystkich zmian z Twojej wiki na ich wiki.

Pełne instrukcje:

(SKOPIOWANE Z GITHUBA Larry'ego Bothy TUTAJ: https://gist.github.com/larrybotha/10650410 ):

---------- ROZPOCZĘCIE KOPIOWANIA-WKLEJENIA Z POWYŻSZEGO GITHUBA GIST ------------

Scal zmiany Wiki z rozwidlonego repozytorium Github

Jest to zainspirowane (lub w zasadzie skopiowane) z How To Merge Github Wiki Changes From One Repository To Another autorstwa Romana Ivanova i służy do zapewnienia, że ​​jeśli coś stanie się z oryginalnym artykułem, informacje pozostaną tutaj ładne i bezpieczne.

Terminologia

OREPO : repozytorium oryginalne - repozytorium utworzone lub utrzymywane przez właściciela

FREPO : rozwidlone repozytorium, które prawdopodobnie ma aktualizacje swojej wiki, ale jeszcze nie w OREPO

Współtworzenie

Jeśli chcesz wnieść swój wkład w wiki repozytorium, które rozwidliłeś, wykonaj następujące czynności:

• rozwidlić repozytorium
• sklonuj tylko wiki na swój komputer: $ g clone [FREPO].wiki.git
• wprowadź zmiany w lokalnym repozytorium rozwidlonych wiki
• wypchnij zmiany do GitHub

Gdy będziesz gotowy, aby powiadomić autora o zmianach, wykonaj następujące czynności:

• otwórz numer w OREPO
• podaj bezpośredni link do repozytorium git swojej wiki, aby ułatwić łączenie: np. [ FREPO ] .wiki.git

Scalanie zmian

Jako właściciel OREPO otrzymałeś wiadomość, że są aktualizacje twojej wiki na czyimś FREPO .

Jeśli zmiany wiki są rozwidlone z najnowszej wiki OREPO , możesz wykonać następujące czynności:

$ git clone [OREPO].wiki.git
$ cd [OREPO].wiki.git

# squashing all FREPO changes
$ git pull [FREPO].wiki.git master

$ git push origin master

Jeśli wiki OREPO wyprzedza miejsce, z którego rozwidliło się FREPO , wykonaj następujące czynności:

$ git clone [OREPO].wiki.git
$ cd [OREPO].wiki.git
$ git fetch [FREPO] master:[FREPO-branch]
$ git checkout [FREPO-branch]

#checkout to last OREPO commit
$ git reset --hard [last-OREPO-commit-hash]

# do massive squash of all FREPO changes
$ git merge --squash HEAD@{1}
$ git commit -m "Wiki update from FREPO - [description]"
$ git checkout master

# cherry-pick newly squashed commit
$ git cherry-pick [OREPO-newly-squashed-commit]
$ git push

---------- KONIEC KOPII-WKLEJENIA Z POWYŻSZEGO GITHUBA GIST ------------

Jeśli możesz mieć dokument o długości jednej strony (właściwie to bardziej mi się podoba), możesz przejąć README.MDi umieścić tam zawartość wiki.

Nie tylko będzie śledzony jako część normalnego repozytorium, ale będzie również wyświetlany na stronie głównej.

Można zacząć od szybkiego odniesienia, a następnie przejść do bardziej szczegółowego opisu / instrukcji, tak aby zwykli użytkownicy najpierw trafili do bardziej ogólnych informacji.