Maintaining a fork with patches in master
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:
- Is there an easier or cleaner way to achieve the same results?
- 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
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
84
add a comment |
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:
- Is there an easier or cleaner way to achieve the same results?
- 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
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
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 '18 at 4:14
add a comment |
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:
- Is there an easier or cleaner way to achieve the same results?
- 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
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
84
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:
- Is there an easier or cleaner way to achieve the same results?
- 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
git github git-fork
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
84
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
84
edited Nov 12 '18 at 9:32
M.Marcello
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
84
asked Nov 12 '18 at 0:05
M.MarcelloM.Marcello
84
asked Nov 12 '18 at 0:05
M.MarcelloM.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 '18 at 4:14
add a comment |
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 '18 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 '18 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 '18 at 4:14
add a comment |
1 Answer
1
active
oldest
votes
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
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 '18 at 9:40
add a comment |
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',
autoActivateHeartbeat: false,
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 '18 at 9:40
add a comment |
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
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 '18 at 9:40
add a comment |
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
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
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
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
answered Nov 12 '18 at 5:40
VonCVonC
841k29426633210
841k29426633210
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 '18 at 9:40
add a comment |
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 '18 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 '18 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 '18 at 9:40
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 '18 at 4:14