How do I go back to a previous build? For example going back to the July 30 state?
There are a number of ways to functionally undo a series of commits in Git. But given that the branch in question is published, and likely shared by several people, I would recommend using git revert here. git revert adds new commits on top of your current branch which undo previous commits. These revert commits can be thought of as mirror images of what was done in previous commits. Something like this should work:
git revert 00bfe1b^..a013402
This should add two commits, one to undo the Aug-9 commit and one to undo the Aug-13 commit.
As a side note, you could have also done this:
git reset --hard HEAD~2
This would have completely nuked the two commits on top of Jul-30. However, this involves rewriting the history of the branch, which isn't desirable if other people may already be sharing this branch with you. In this case, just play it safe and use git revert.
To view (browse the file tree) the repository state at a certain commit given at least the first four characters of commit's hash, the following URL schema for GitHub can be used (at the time of writing):
https://github.com/{username}/{repository name}/tree/{hash}
If you want to hard reset your GitHub repository to a specific commit, do a git reset --hard {hash} in your local (stored on your computer) repository then force push it to a remote repository (like GitHub) via git push --force.
Of course, hard resets are dangerous. You can git revert or git reset and stash unstaged changes, and I'm sure there are other ways to achieve similar effects.
Related
A PR was accidentally merged into main before it had been properly sanitized which I think has resulted in their being no revert option. The lack of an option suggests that it is not possible/simple?
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request
I have write permissions to the repo in question.
A revert is just a commit like any other commit. So, you can certainly revert the merge commit and push that, possibly as a PR if you're not able to push directly to main.
However, note that this reverses the effect of the merge without undoing the topology. You won't be able to merge those same commits again later.
In theory you can force main to go backwards to a commit before this bad merge took place, erasing the unwanted commits since then, or force main to point directly to the commit at the end of the good branch — namely by using a hard reset. But in practice, where you're sharing this repo with others, that would be a pretty terrible idea.
I am using git on VS2019
I was wondering if there is a way to remove old commits but always keep the latest code. The reason is that when I work on a big change, I do a lot of commits after checking every small step but at the end it is annoying when I click on view history and need to search an old commit to compare the changes. I would like to remove specific commits but leave the changes. In that way I will see on history only the main milestones of the developing process. There is a way to do that??
It sounds like in these scenarios, you're developing a new feature, in which case you should be using a branch+pull request approach to development. During the pull request, you can do a squash merge. It's not all in the command line, but that might be for the best anyway.
If you're already working within a feature branch, then I like VonC's approach.
It seems that you want the git rebase feature.
If you know how many commits you want to squash together, you can use
git rebase -i HEAD~N
You can also do it in interactive mode:
git rebase --interactive HEAD~N
Be aware that if you merging commits you have already pushed, you may have trouble with your next push.
For more details, see: https://www.internalpointers.com/post/squash-commits-into-one-git
You can follow a workflow similar to "Git better with fixups " from Atul Sharma
For the commits which are incremental improvement for the same step, use git commit --fixup small step, which allows you to "do a lot of commits after checking every small step".
(You can see it in Git Extension in Visual Studio)
But at the end, you can cleanup all those small steps with git rebase --interactive --autosquash <First step commit> (assuming you have not pushed those commits yet)
That way, you end up with a cleaner history.
This question already has answers here:
How do I revert a Git repository to a previous commit?
(41 answers)
Closed 4 years ago.
I realize this isn't directly a coding question, but GitHub is widely used and I haven't seen how to do this, so I figured I'd ask as I'm trying to figure it out.
Using GitHub how do I go about backtracking a development branch to a previous push point?
For example, let's say I have a dev branch and I push faulty code, how do I backtrack to a previous point in that branch in the event I need to?
I'd prefer to see how to do this from the command line, but in the web UI is fine as well.
Assuming your branch with the bad commit(s) has already been published to GitHub, and other users may have already pushed it, then you typically would not literally rollback that branch. Instead, you would use git revert to functionally undo the bad commit:
git revert 1a7h3jxk # where 1a7h3jxk is the SHA-1 hash of the bad commit
git revert actually adds a new commit which functionally undoes the commit you specify as a parameter. It also allows syntax for specifying a range of commits.
If you really want to formally "backtrack" your branch, you could do a hard reset to remove the bad commit(s). For example, to actually remove a single bad commit you could do:
git reset --hard HEAD~1
git push --force origin your_branch
But note carefully that doing a hard reset means that you are rewriting the history of your branch. This means you have to force push (read: overwrite) the version of the branch on the remote. As mentioned above, this option should not be used if anyone shared this branch besides you.
There is a library with a branch named dev which I created a fork of here. I then made a commit to my fork so that it would better suit my needs, and I intend to make further commits in the future. However, as the library is still in development I would also like my fork to stay up to date with the changed made in the original dev branch so that it has all of the latest bugfixes and such. Is it possible to sync the two branches while keeping my personal changes?
Edit:
I've looked at the possible duplicate and it seems like an appropriate answer but I just want to clear up one thing before I accept it - I need to sync to just the dev branch and not the whole repo, so would I do git rebase upstream/dev? What does git rebase upstream/master even do?
You'll want to periodically rebase your fork. Alternatively, you could merge the changes in if you'd like to preserve the history.
I'm trying to figure out how to fix a merge problem me and my team are facing. I'm working on this project at school, and my team has made a lot of progress, but one of the team members who didn't know what he was doing force merges his code into the master branch. His branch is like 2 days old and we've already implemented a lot of new functionality since time, his branch is probably 20 or so commits away from head. I've tried rolling back to a stable master branch but his branch is intermingled with the stable so I can't seem to retrieve the stable back. Any suggestions? we are fairly new to git, but that person had no idea what was going on and just force merged his code without resolving the commits.
Go and sit on his computer.
Type git reflog, it will show you the full commit history (as well as other things). Find out the last good commit id , check it out git checkout SHA-1. create branch at this point and commit it back again. Once you are on the right commit your repository will "get back" to the last good place.
Another option is to perform a git bisect and to find out what is the bad commit.
Click here for blog about reflog
Click here for blog about bisect
Good luck.