It is possible in GitKraken to revert changes of a single file to an earlier commit instead of reverting an entire commit?
Answer
A revert in the git-sense of it can only be performed on a commit. It introduces a new commit that exactly negates the reverted commits' changes. See here. GitKraken supports this: right click on a commit, Revert <branch> to this commit.
What you want to accomplish, however, can be done via git checkout. I do not think GitKraken supports this funtionality for a single file yet. You can, however, use the command line.
Reset single file via command line
git checkout <commit> <file>
Check out a previous version of a file. This turns the <file> that
resides in the working directory into an exact copy of the one from
<commit> and adds it to the staging area.
Documentation can be found here.
git checkout HEAD~1 <filename> will thus reset a single file to the commit before the current HEAD.
You can accomplish this in the GitKraken UI, but it's a little roundabout:
Revert the most recent commit(s) back to where the file was deleted, but when GitKraken asks if you want to immediately commit the reversion, click no.
Unstage all changes
Stage only the add for the file you're trying to restore
Right click in Unstaged, and Discard all
This should leave you with only an add for the one file you wanted to restore. Commit that, and now you've got your one file back.
Note that this can work across numerous commits, not just one... but since it's going to have to roll back everything from all of those commits, and then discard all of the rollbacks (except one) it can be quite slow if involves massive changes. In situations like this, it is probably better to use the git CI as suggested in kowsky's answer.
Although it doesn't strictly involves using git commands, GitKraken offers the possibility to visualize the content of any project file at any given commit.
When acting on a single file, it might be much easier to copy/paste the targeted commit file's content than using complicated git commands that might very well end up messing your whole project's commit history.
To achieve this, simply:
Open your git project in GitKraken
Click on the desired commit in the commit history line
In the right panel, check the View all files checkbox
Locate the desired project file and click on it
The file content will be displayed in the main panel
You can now copy/paste the content
Simple and efficient when you only need to revert a very limited number of files...
GitKraken 7.3.0 (probably older versions too) does allow for effectively running git checkout on a single file in the UI: Right click on the file under "unstaged files" and select "discard changes". Works on folders as well.
(This answer was previously a comment to the accepted answer)
You can make an UNDO to the last commit edit it and after that make a Force push to overwrite that. Works very well
Hope GitKraken can do this, as "TortoiseGit" does.
Related
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.
Basically what has happened is this:
I moved a bunch of files from one directory to another directory.
I then committed my change and pushed it.
Then I notice that my "move" actually wasn't a move but Mercurial, I guess, actually copied the files I wanted to move and pasted them in the new directory and then deleted the original files.
The unintended result of this is that all the history is lost since it is no longer the old files but new ones.
So what I would like to know is how do I revert/rollback/backout this change?
I have read about all three ways but I'm still not sure which is the best way to approach this. I just want to backout my push so that I can move the files correctly without losing all the history.
You can't directly "undo" a push but there are ways to essentially negate its effects.
Option 1: The most straightforward option is if you have full control over all clones which have received the pushed commit which was in error. If so, use hg strip on all of them to remove the bad commit(s).
Option 2: If you cannot do that, you could delete the incorrectly added files and revert the deletion of the original files (example), and then just redo the operation as you originally intended.
Option 3: Update back to the commit prior to the bad one. Then use hg move to correctly relocate the files, and commit that which will create a new head (since you were working off a revision older than the current tip). Then merge this new head with the tip. That should cause the history to be retained.
I'm new to github and have been working on a group project for school. Recently it turned out we were missing some stuff and nothing was organized (every file was just uploaded into the main directory) so I removed everything using a command in the github shell. Then I proceeded to make files and organize all the code and re-upload and store everything in there.
However, when I did this, I had to keep committing every time I made a new folder and stored a bunch of files in it. I would like to keep the changes made during those commits (because I created folders and re-uploaded the stuff), but I want to remove those commits from the history because they are cluttering up the project.
Is this possible, and if so can you please walk me through the steps. Also I'm new to github so I don't know much.
Here is a picture of the ones I want to remove from my history because they are cluttering up the screen (see red marks):
Thanks :)
EDIT: PLEASE NOTE: I don't want to revert the changes, I just want all those history to be removed because they are cluttering up the commit history.
You should use:
git rebase -i HEAD~14
To rebase and squash your unwanted commits. Just use p to mark the last commit and use f to mark the unwanted commits for squashing it with the previous commits. This will remove it from commit log keeping the changes.
More info: https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-Rebasing
I'm new to github and currently only starting off using github for mac.
I have taken a clone of my client's website and made some development changes locally. Note: I'm literally working with the files in the directory I sync with.
I want to push only one small change as the rest is still under development. Is it possible to push only the one file?
Git pushes deal with commits, not files. You'll need to create a commit that contains your selected changes. This is one area where Git's index is really handy.
Let's say you've modified two files, foo and bar.
If you want to commit only the changes to foo, using the command line you can do
git add foo
git commit
This will create a new commit updating foo, but bar's changes will remain only in your working copy. You can now push the new commit.
It's been a while since I've used the graphical GitHub tools, and I've only used them on Windows, but I believe the way to commit only certain files is to check or uncheck the box beside each file before you commit. You can see these checkboxes in their documentation:
You can go even further. If some of the changes in bar should be part of a commit, but not all of them, you can do something like git add --patch, which will break your changes up into chunks and prompt you for the ones to add to the index (these are the ones that will be included when you commit).
On GitHub for Mac you can do this too:
Select one or more lines to commit by clicking on the line numbers in the gutter. In the latest release, you can select a block of changes at a time. Hover over the right hand side of the line numbers to get a preview of what will be selected, and click to select.
See the documentation for git-add for details.
There are certain files in my repository that I want to be able to edit locally. But I never want to push any changes to those files to the server. Is it possible for me to set that up?
EDIT: to clarify, I do want to pull changes that others have made. But I don't want to push my changes.
It's not easily possible. Mercurial doesn't push and pull files it pushes and pulls changesets. Your only route would be to never commit those files. Ignoring them isn't an option because they're already tracked (added) and tracked always overrides ignored.
You could explicitly exclude them on commits like.
hg commit -X a-file-I-changed -X another-file
And since you'll eventually forget to do that you could set up an alias in your hgrc:
[alias]
mycommit = -X a-file-I-changed -X another-file
However, I'm going to go out on a limb and guess you're talking about a configuration file like a database settings file. The best way to handle that is to commit not database.conf (or whatever it's called) but instead database.conf.sample and then have your launch script copy database.conf.sample to database.conf if it doesn't already exist. That's the normal practice.
If your change is substantial consider making it a patch in a Mercurial Queue. You can pop your change, pull their changes, and then push your change back on to the working dir. If it's a change you couldn't bear to lose you can make make the queue a repository of its own, and then clone that repository elsewhere.
A Ry4an writes, you can exclude the file when you commit. A colleague of mine has made a simple extension that will automate this in simple cases:
https://www.mercurial-scm.org/wiki/ExcludeExtension
https://bitbucket.org/aragost/exclude/
The non-simple case is a merge -- Mercurial wont let you exclude files when you commit a merge. For now, you'll have to move the modified file aside, revert it, and then move it back after the merge. Patches are welcome to handle this case!