Jak zarządzać łatami projektów open source, które nie mogą przejść na wyższy poziom?

Question

Pracuję nad projektem open source. Teraz ukończyłem kilka poprawek, które są istotne dla działalności firmy i nie mogę popychać tych łatek w górę.

Muszę więc przechowywać te łatki w moim lokalnym repozytorium git. Muszę wyciągnąć nowe łatki z góry i rozwiązać konflikty z moimi łatkami.

Ktoś ma podobne doświadczenie i jak z nim pracować wygodnie?

Aktualizacja: Aktualizacja: Podobnie jak w przypadku posiadania kilku łatek nie można zaakceptować jądra systemu Linux, ponieważ te łatki są nieprzyjazne dla jądra. Muszę codziennie budować jądro i nie chcę codziennie pisać ręcznie. Czy istnieją jakieś narzędzia, które mogłyby mi pomóc?

Answer 1

Po pierwsze przed wprowadzeniem zmian w projektu-

1. create a branch 
    2. Change to that branch for any changes you make 
    3. To pull the new patches from the upstream revert back to the master branch and then git pull. 

Polecenia do tworzenia oddziału i zmiany są następujące

1. $ git branch <branch name>   // To create a new branch 
2. $ git checkout <branch name>   // To change to the branch 
3. $ git checkout master    // To change to the master branch 

Answer 2

Pracuję nad projektem open source. Teraz ukończyłem kilka poprawek, które są istotne dla działalności firmy i nie mogę popychać tych łatek w górę.

Jeśli współpracujesz nad projektem w Git, szczególnie jeśli jest to oprogramowanie open source, ludzie prawdopodobnie nie pozwolą ci po prostu przeforsować wszystkiego, co chcesz, do repozytorium. Prawdopodobnie chcesz przesłać zmiany w żądaniu pobrania lub wysłać poprawki do jednego z menedżerów projektu.

można przeczytać więcej na temat współpracy z innymi ludźmi w Git z tych Pro Git rozdziałów:

1. Distributed Workflows
2. Contributing to a Project

Jeśli jesteś zainteresowany, można również przeczytać o how GitHub uses pull requests.

Answer 3

Jestem nieco zaskoczony, że odpowiedzi do tej pory nie wydają się brać pod uwagę dwie rzeczy:

1. Nie wszystkie modyfikacje dokonane przez programistów jest przeznaczony do lub nadaje się do przedłożenia projektu open source.
2. Nawet jeśli tak jest, jeśli w repozytorium znajduje się aktualizacja podczas pracy nad kodem, bardzo często chcesz scalić te zmiany z kopią roboczą.

Dobrą rzeczą jest to, że skoro pracujesz z przyzwoitą wersją oprogramowania sterującego, zwykle nie jest tak trudno zrobić to, czego potrzebujesz. Jestem facetem wywrotowym (ze względu na politykę firmy), więc nie znam się konkretnie na GIT, ale po przeczytaniu this wiki article, wygląda na to samo. Nie musisz ponownie nakładać poprawek, o ile dopasujesz pliki do lokalnego repozytorium. Możesz zaktualizować lokalną kopię za pomocą już zainstalowanych poprawek!

Twój niestandardowy kod prawdopodobnie dotyka bardzo małej części kodu repozytorium. Prawdopodobnie większość zmian w repozytorium nie dotknie tego samego kodu, który dotknąłeś.Będziesz po prostu musiał użyć polecenia git pull, aby pobrać cały zaktualizowany kod. Kiedy dotknięte sekcje zostaną zmienione w repozytorium, git zrobi to najlepiej scalając te zmiany. Jedyny czas, w którym musisz przekazać pliki do edycji to, że git wykrywa konflikt, którego nie może rozwiązać. Artykuł, o którym wspomniałem, mówi o tym wcześniej.

Możesz użyć swojego ulubionego edytora tekstu, ale w tym przypadku całkiem wygodnie jest użyć narzędzia do scalania trójstronnego. Meld jest jednym z takich narzędzi dla Linuksa, ale jestem pewien, że jest tam wiele.

Answer 4

Oto możliwy przepływ pracy.

Początkowa konfiguracja

git clone --origin 'upstream' http://example.com/project.git 
cd project 
git checkout master 
git checkout -b patched 
# make changes 
git add --all 
git commit -m 'internal patches' 

New upstream zmienia

git checkout master 
git pull upstream 
git checkout patched 
git rebase master 

Referencje:

• rolf@Supenta: Git: How to consistently maintain local patches
• Maintaining a local patch set with git - Tony Finch