Maintaining a fork with patches in master











up vote
1
down vote

favorite
1












I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.



What I want to achieve:




  • The GitHub page of the fork should point to the patched version of the project instead of the original one.

  • I should be able to easily merge new upstream code while preserving a separate history for my own commits.


My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.



Questions:




  1. Is there an easier or cleaner way to achieve the same results?

  2. Should I fork via GitHub web-interface and then move master, or should I create the repository locally as described in this answer?










share|improve this question
























  • This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
    – larsks
    Nov 12 at 4:14















up vote
1
down vote

favorite
1












I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.



What I want to achieve:




  • The GitHub page of the fork should point to the patched version of the project instead of the original one.

  • I should be able to easily merge new upstream code while preserving a separate history for my own commits.


My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.



Questions:




  1. Is there an easier or cleaner way to achieve the same results?

  2. Should I fork via GitHub web-interface and then move master, or should I create the repository locally as described in this answer?










share|improve this question
























  • This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
    – larsks
    Nov 12 at 4:14













up vote
1
down vote

favorite
1









up vote
1
down vote

favorite
1






1





I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.



What I want to achieve:




  • The GitHub page of the fork should point to the patched version of the project instead of the original one.

  • I should be able to easily merge new upstream code while preserving a separate history for my own commits.


My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.



Questions:




  1. Is there an easier or cleaner way to achieve the same results?

  2. Should I fork via GitHub web-interface and then move master, or should I create the repository locally as described in this answer?










share|improve this question















I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.



What I want to achieve:




  • The GitHub page of the fork should point to the patched version of the project instead of the original one.

  • I should be able to easily merge new upstream code while preserving a separate history for my own commits.


My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.



Questions:




  1. Is there an easier or cleaner way to achieve the same results?

  2. Should I fork via GitHub web-interface and then move master, or should I create the repository locally as described in this answer?







git github git-fork






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 12 at 9:32

























asked Nov 12 at 0:05









M.Marcello

84




84












  • This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
    – larsks
    Nov 12 at 4:14


















  • This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
    – larsks
    Nov 12 at 4:14
















This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14




This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14












1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










A fork is just a more formal way to link those two GitHub repo.



You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.



git fetch upstream
git checkout master
git rebase upstream/master





share|improve this answer





















  • That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
    – M.Marcello
    Nov 12 at 9:40











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53254484%2fmaintaining-a-fork-with-patches-in-master%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote



accepted










A fork is just a more formal way to link those two GitHub repo.



You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.



git fetch upstream
git checkout master
git rebase upstream/master





share|improve this answer





















  • That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
    – M.Marcello
    Nov 12 at 9:40















up vote
0
down vote



accepted










A fork is just a more formal way to link those two GitHub repo.



You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.



git fetch upstream
git checkout master
git rebase upstream/master





share|improve this answer





















  • That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
    – M.Marcello
    Nov 12 at 9:40













up vote
0
down vote



accepted







up vote
0
down vote



accepted






A fork is just a more formal way to link those two GitHub repo.



You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.



git fetch upstream
git checkout master
git rebase upstream/master





share|improve this answer












A fork is just a more formal way to link those two GitHub repo.



You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.



git fetch upstream
git checkout master
git rebase upstream/master






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 12 at 5:40









VonC

825k28425943129




825k28425943129












  • That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
    – M.Marcello
    Nov 12 at 9:40


















  • That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
    – M.Marcello
    Nov 12 at 9:40
















That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40




That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53254484%2fmaintaining-a-fork-with-patches-in-master%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bressuire

Vorschmack

Quarantine