Mixing
Regarding git force push
I cloned a repository to my local machine.Then, i created a new branch (from the current master )using git checkout -b dev/abc/test1. I am the only person working on this branch. I worked on this branch for a few hours and then made commits and did git pushand created a pull request. Reviewers made some comments on this pull request.
Before starting to work on those comments, i did, git checkout master, then, git pull to update master branch. Later, i wanted to merge those changes(there were a lot many changes in master since i had last updated it) to my branch dev/abc/test1.
Hence, i did git checkout dev/abc/test1. Then i did git reset --hard origin/master and then git merge origin/master. So, all my changes from this branch were lost as expected. I manually copy pasted the changes i made from the pull request. Now i started to work on those reviewer comments and fixed all of them, did a git commit and then git push but only to see the message
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
To avoid this, i went ahead with git push --force.
Will this have any negative impact? I see one of the comments saying here Cannot push to GitHub - keeps saying need merge that 'forcing' is most of the time, if not always, the wrong answer. Will my approach impact the repository in any negative way ? (As a side note, i am the only individual contributor to the branch dev/abc/test1)
git push git-push
edited Nov 19 '18 at 16:52
phd
20.9k52442
asked Nov 19 '18 at 15:58
fsociety
3201415
add a comment |
I cloned a repository to my local machine.Then, i created a new branch (from the current master )using git checkout -b dev/abc/test1. I am the only person working on this branch. I worked on this branch for a few hours and then made commits and did git pushand created a pull request. Reviewers made some comments on this pull request.
Before starting to work on those comments, i did, git checkout master, then, git pull to update master branch. Later, i wanted to merge those changes(there were a lot many changes in master since i had last updated it) to my branch dev/abc/test1.
Hence, i did git checkout dev/abc/test1. Then i did git reset --hard origin/master and then git merge origin/master. So, all my changes from this branch were lost as expected. I manually copy pasted the changes i made from the pull request. Now i started to work on those reviewer comments and fixed all of them, did a git commit and then git push but only to see the message
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
To avoid this, i went ahead with git push --force.
Will this have any negative impact? I see one of the comments saying here Cannot push to GitHub - keeps saying need merge that 'forcing' is most of the time, if not always, the wrong answer. Will my approach impact the repository in any negative way ? (As a side note, i am the only individual contributor to the branch dev/abc/test1)
git push git-push
edited Nov 19 '18 at 16:52
phd
20.9k52442
asked Nov 19 '18 at 15:58
fsociety
3201415
1
It's ok for this case, I guess.
– Sajib Khan
Nov 19 '18 at 16:03
add a comment |
I cloned a repository to my local machine.Then, i created a new branch (from the current master )using git checkout -b dev/abc/test1. I am the only person working on this branch. I worked on this branch for a few hours and then made commits and did git pushand created a pull request. Reviewers made some comments on this pull request.
Before starting to work on those comments, i did, git checkout master, then, git pull to update master branch. Later, i wanted to merge those changes(there were a lot many changes in master since i had last updated it) to my branch dev/abc/test1.
Hence, i did git checkout dev/abc/test1. Then i did git reset --hard origin/master and then git merge origin/master. So, all my changes from this branch were lost as expected. I manually copy pasted the changes i made from the pull request. Now i started to work on those reviewer comments and fixed all of them, did a git commit and then git push but only to see the message
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
To avoid this, i went ahead with git push --force.
Will this have any negative impact? I see one of the comments saying here Cannot push to GitHub - keeps saying need merge that 'forcing' is most of the time, if not always, the wrong answer. Will my approach impact the repository in any negative way ? (As a side note, i am the only individual contributor to the branch dev/abc/test1)
git push git-push
edited Nov 19 '18 at 16:52
phd
20.9k52442
asked Nov 19 '18 at 15:58
fsociety
3201415
I cloned a repository to my local machine.Then, i created a new branch (from the current master )using git checkout -b dev/abc/test1. I am the only person working on this branch. I worked on this branch for a few hours and then made commits and did git pushand created a pull request. Reviewers made some comments on this pull request.
Before starting to work on those comments, i did, git checkout master, then, git pull to update master branch. Later, i wanted to merge those changes(there were a lot many changes in master since i had last updated it) to my branch dev/abc/test1.
Hence, i did git checkout dev/abc/test1. Then i did git reset --hard origin/master and then git merge origin/master. So, all my changes from this branch were lost as expected. I manually copy pasted the changes i made from the pull request. Now i started to work on those reviewer comments and fixed all of them, did a git commit and then git push but only to see the message
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
To avoid this, i went ahead with git push --force.
Will this have any negative impact? I see one of the comments saying here Cannot push to GitHub - keeps saying need merge that 'forcing' is most of the time, if not always, the wrong answer. Will my approach impact the repository in any negative way ? (As a side note, i am the only individual contributor to the branch dev/abc/test1)
git push git-push
git push git-push
edited Nov 19 '18 at 16:52
phd
20.9k52442
asked Nov 19 '18 at 15:58
fsociety
3201415
edited Nov 19 '18 at 16:52
phd
20.9k52442
asked Nov 19 '18 at 15:58
fsociety
3201415
edited Nov 19 '18 at 16:52
phd
20.9k52442
edited Nov 19 '18 at 16:52
phd
20.9k52442
edited Nov 19 '18 at 16:52
phd
20.9k52442
20.9k52442
asked Nov 19 '18 at 15:58
fsociety
3201415
asked Nov 19 '18 at 15:58
fsociety
3201415
asked Nov 19 '18 at 15:58
fsociety
3201415
3201415
1
It's ok for this case, I guess.
– Sajib Khan
Nov 19 '18 at 16:03
add a comment |
1
It's ok for this case, I guess.
– Sajib Khan
Nov 19 '18 at 16:03
1
1
It's ok for this case, I guess.
– Sajib Khan
Nov 19 '18 at 16:03
It's ok for this case, I guess.
– Sajib Khan
Nov 19 '18 at 16:03
add a comment |
3 Answers
3
active
oldest
votes
When you did git push --force, you forcibly overwrote the remote dev/abc/test1 branch. This means that the previous remote branch was potentially erased for good. There should be no side effects in your case, because you are the only one using the branch. The reason why force pushing is generally bad, is because in general remote branches are shared by several developers at a time. When you rewrite the history of a remote branch, you can cause havoc for anyone else sharing the branch. When that other person goes to git pull, they will see a new history coming in.
Note that, perhaps ironically, the best thing for you to have done would be to just replace your local copy of dev/abc/test1 with the remote branch. So, instead of doing a hard reset to master, you could have done a hard reset to the dev/abc/test1 tracking branch, via:
git reset --hard origin/dev/abc/test1
This would have undone whatever you did locally which might have prompted you to reset to master.
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
add a comment |
In this case you are rewriting the history of your dev/abc/test1 branch. As long as nobody else is using this branch then it should be OK.
I would suggest the following workflow, that will mean you don't need to force push next time.
git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push
This would have the same result while not rewriting history.
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
add a comment |
If you are in a GitHub pull request review process, then force pushing is acceptable. Doing so will update your pull request automatically and GitHub will detect what has changed.
Another common workflow for the review process is to just add commits that address the feedback. So you can just push those directly (without force). At the end, it is then usually up to the person responsible for merging to squash those commits so that the individual fixes that went on top of your initial PR will not appear separately.
Force pushing is generally just frowned upon because it often means that you are rewriting history (something that rebasing does). And publishing rewritten history is a very good way to mess with all your team members, so you should really avoid that at all costs. A pull request is however always considered to be in a fluid state (often requiring rebasing to match ongoing development on the base branch), so people are less likely to expect that to have a consistent history.
answered Nov 19 '18 at 16:04
poke
208k46327386
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%2f53378389%2fregarding-git-force-push%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
When you did git push --force, you forcibly overwrote the remote dev/abc/test1 branch. This means that the previous remote branch was potentially erased for good. There should be no side effects in your case, because you are the only one using the branch. The reason why force pushing is generally bad, is because in general remote branches are shared by several developers at a time. When you rewrite the history of a remote branch, you can cause havoc for anyone else sharing the branch. When that other person goes to git pull, they will see a new history coming in.
Note that, perhaps ironically, the best thing for you to have done would be to just replace your local copy of dev/abc/test1 with the remote branch. So, instead of doing a hard reset to master, you could have done a hard reset to the dev/abc/test1 tracking branch, via:
git reset --hard origin/dev/abc/test1
This would have undone whatever you did locally which might have prompted you to reset to master.
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
add a comment |
When you did git push --force, you forcibly overwrote the remote dev/abc/test1 branch. This means that the previous remote branch was potentially erased for good. There should be no side effects in your case, because you are the only one using the branch. The reason why force pushing is generally bad, is because in general remote branches are shared by several developers at a time. When you rewrite the history of a remote branch, you can cause havoc for anyone else sharing the branch. When that other person goes to git pull, they will see a new history coming in.
Note that, perhaps ironically, the best thing for you to have done would be to just replace your local copy of dev/abc/test1 with the remote branch. So, instead of doing a hard reset to master, you could have done a hard reset to the dev/abc/test1 tracking branch, via:
git reset --hard origin/dev/abc/test1
This would have undone whatever you did locally which might have prompted you to reset to master.
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
add a comment |
When you did git push --force, you forcibly overwrote the remote dev/abc/test1 branch. This means that the previous remote branch was potentially erased for good. There should be no side effects in your case, because you are the only one using the branch. The reason why force pushing is generally bad, is because in general remote branches are shared by several developers at a time. When you rewrite the history of a remote branch, you can cause havoc for anyone else sharing the branch. When that other person goes to git pull, they will see a new history coming in.
Note that, perhaps ironically, the best thing for you to have done would be to just replace your local copy of dev/abc/test1 with the remote branch. So, instead of doing a hard reset to master, you could have done a hard reset to the dev/abc/test1 tracking branch, via:
git reset --hard origin/dev/abc/test1
This would have undone whatever you did locally which might have prompted you to reset to master.
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
When you did git push --force, you forcibly overwrote the remote dev/abc/test1 branch. This means that the previous remote branch was potentially erased for good. There should be no side effects in your case, because you are the only one using the branch. The reason why force pushing is generally bad, is because in general remote branches are shared by several developers at a time. When you rewrite the history of a remote branch, you can cause havoc for anyone else sharing the branch. When that other person goes to git pull, they will see a new history coming in.
Note that, perhaps ironically, the best thing for you to have done would be to just replace your local copy of dev/abc/test1 with the remote branch. So, instead of doing a hard reset to master, you could have done a hard reset to the dev/abc/test1 tracking branch, via:
git reset --hard origin/dev/abc/test1
This would have undone whatever you did locally which might have prompted you to reset to master.
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
answered Nov 19 '18 at 16:04
Tim Biegeleisen
218k1387140
218k1387140
add a comment |
add a comment |
In this case you are rewriting the history of your dev/abc/test1 branch. As long as nobody else is using this branch then it should be OK.
I would suggest the following workflow, that will mean you don't need to force push next time.
git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push
This would have the same result while not rewriting history.
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
add a comment |
In this case you are rewriting the history of your dev/abc/test1 branch. As long as nobody else is using this branch then it should be OK.
I would suggest the following workflow, that will mean you don't need to force push next time.
git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push
This would have the same result while not rewriting history.
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
add a comment |
In this case you are rewriting the history of your dev/abc/test1 branch. As long as nobody else is using this branch then it should be OK.
I would suggest the following workflow, that will mean you don't need to force push next time.
git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push
This would have the same result while not rewriting history.
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
In this case you are rewriting the history of your dev/abc/test1 branch. As long as nobody else is using this branch then it should be OK.
I would suggest the following workflow, that will mean you don't need to force push next time.
git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push
This would have the same result while not rewriting history.
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
answered Nov 19 '18 at 16:03
Jim Wright
4,0081525
4,0081525
add a comment |
add a comment |
If you are in a GitHub pull request review process, then force pushing is acceptable. Doing so will update your pull request automatically and GitHub will detect what has changed.
Another common workflow for the review process is to just add commits that address the feedback. So you can just push those directly (without force). At the end, it is then usually up to the person responsible for merging to squash those commits so that the individual fixes that went on top of your initial PR will not appear separately.
Force pushing is generally just frowned upon because it often means that you are rewriting history (something that rebasing does). And publishing rewritten history is a very good way to mess with all your team members, so you should really avoid that at all costs. A pull request is however always considered to be in a fluid state (often requiring rebasing to match ongoing development on the base branch), so people are less likely to expect that to have a consistent history.
answered Nov 19 '18 at 16:04
poke
208k46327386
add a comment |
If you are in a GitHub pull request review process, then force pushing is acceptable. Doing so will update your pull request automatically and GitHub will detect what has changed.
Another common workflow for the review process is to just add commits that address the feedback. So you can just push those directly (without force). At the end, it is then usually up to the person responsible for merging to squash those commits so that the individual fixes that went on top of your initial PR will not appear separately.
Force pushing is generally just frowned upon because it often means that you are rewriting history (something that rebasing does). And publishing rewritten history is a very good way to mess with all your team members, so you should really avoid that at all costs. A pull request is however always considered to be in a fluid state (often requiring rebasing to match ongoing development on the base branch), so people are less likely to expect that to have a consistent history.
answered Nov 19 '18 at 16:04
poke
208k46327386
add a comment |
If you are in a GitHub pull request review process, then force pushing is acceptable. Doing so will update your pull request automatically and GitHub will detect what has changed.
Another common workflow for the review process is to just add commits that address the feedback. So you can just push those directly (without force). At the end, it is then usually up to the person responsible for merging to squash those commits so that the individual fixes that went on top of your initial PR will not appear separately.
Force pushing is generally just frowned upon because it often means that you are rewriting history (something that rebasing does). And publishing rewritten history is a very good way to mess with all your team members, so you should really avoid that at all costs. A pull request is however always considered to be in a fluid state (often requiring rebasing to match ongoing development on the base branch), so people are less likely to expect that to have a consistent history.
answered Nov 19 '18 at 16:04
poke
208k46327386
If you are in a GitHub pull request review process, then force pushing is acceptable. Doing so will update your pull request automatically and GitHub will detect what has changed.
Another common workflow for the review process is to just add commits that address the feedback. So you can just push those directly (without force). At the end, it is then usually up to the person responsible for merging to squash those commits so that the individual fixes that went on top of your initial PR will not appear separately.
Force pushing is generally just frowned upon because it often means that you are rewriting history (something that rebasing does). And publishing rewritten history is a very good way to mess with all your team members, so you should really avoid that at all costs. A pull request is however always considered to be in a fluid state (often requiring rebasing to match ongoing development on the base branch), so people are less likely to expect that to have a consistent history.
answered Nov 19 '18 at 16:04
poke
208k46327386
answered Nov 19 '18 at 16:04
poke
208k46327386
answered Nov 19 '18 at 16:04
poke
208k46327386
answered Nov 19 '18 at 16:04
poke
208k46327386
208k46327386
add a comment |
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.
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.
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%2f53378389%2fregarding-git-force-push%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
1
It's ok for this case, I guess.
– Sajib Khan
Nov 19 '18 at 16:03