Ah ah! Checkout the previous commit, then checkout the master.
git checkout HEAD^
git checkout -f master
Ah ah! Checkout the previous commit, then checkout the master.
git checkout HEAD^
git checkout -f master
As others have pointed out one could just delete all the files in the repo and then check them out. I prefer this method and it can be done with the code below
git ls-files -z | xargs -0 rm
git checkout -- .
or one line
git ls-files -z | xargs -0 rm ; git checkout -- .
I use it all the time and haven't found any down sides yet!
For some further explanation, the -z appends a null character onto the end of each entry output by ls-files, and the -0 tells xargs to delimit the output it was receiving by those null characters.
Am I using git push --force the right way?
Branching for dummies?
Hello everyone,
I would like to know if I'm using git push --force the right way. Here is my scenario:
-
I branched off master (let's call my branch dev1) which I did some work on and then pushed up remotely
-
A ton of work has been done on `master` I've been working on dev1 locally
-
I want my local dev1 branch to have all the updated changes that master has so I rebased
-
At this point, my local dev1 is way out of sync with remote dev1. Git is saying if I want to sync them up then I need to do a git pull (but I definitely don't want to pull the changes down from the remote branch to my newer, local branch).
Assuming no one else works on dev1, am I supposed to git push --force to sync local `dev1` to remote `dev1`? If not, what are my alternatives?
If you want all changes from master in dev_branch, then:
git switch dev_branch
git reset --hard master
If you have dev_branch pushed to a remote already, you have to do:
git push --force
To force-push the branch to the remote. Warning: This will break the history of the branch for people who cloned it before! Then, other people will have to do a git pull --rebase on the dev_branch to get the changes.
You can also rename the dev branch to something old and then make a new branch from master with the same name:
git branch -m dev_branch old_dev_branch
git branch -m master dev_branch
Or, use the ours strategy — not sure why it wouldn't work for you:
git checkout master
git merge -s ours dev_branch
git checkout dev_branch
git merge master
Why do that? You can delete the branch if it isn't needed anymore (But why? Branches cost next to nothing.). Or you can rename it:
git branch -m dev_branch obsolete_dev
Or you could do this to delete it:
git branch -D dev_branch
Now create a new branch off master (assuming you are on it):
git branch dev_branch
See git branch --help for further options (setting up remotes and all that jazz).
If you now have new branches, you'll have to synchronize with any peer repositories.
Best way to avoid hassle: Have an "active" development branch, if it goes stale, abandon it and create a new one. No history lost that way (could prove crucial sometime).
Have e.g. a branch for each major version, develop on branches off those to fix version bugs, master forges ahead. Use cherry-pick and perhaps merges to port fixes to older versions.
I need someone to explain this to me because I feel like an idiot and I'm getting frustrated. This is at least the third time I've tried to get even a rudimentary understanding of git and it just doesn't take.
I'm walking through this guide because based on the title it should be my speed: https://medium.com/@rukeeojigbo/git-basics-an-idiots-guide-99445a56bd65
Switching between branches sounds simple enough. So I create FirstBranch and edit a text file in it. Cool, git status lets me know there are new changes it detected. Well I don't want to commit anything yet, I want to continue playing around with branches. So I create SecondBranch and check the text file. The text file has the same content that it did on FirstBranch. I guess that makes sense since we were sitting in FirstBranch when we created SecondBranch. I edit the text file with some blurb about it being in SecondBranch. Branches are basically just folders I can swap between right, so let's hop back over to FirstBranch and see that other version of the text file that doesn't have any references to SecondBranch. Oh it does have references to SecondBranch, which means this doesn't work at all the way I thought it did. Now I'm just confused and frustrated.
I need an idiot's guide to git and I'm beginning to think one doesn't exist because it's simply too complex of a tool for me and I'm going to just go back to manually making dated copies of the project folder every time I need to snapshot progress.