commitgitgithub
I am fairly new to Github and have come across an amateur-ish problem.
I have been asked to do a code review and have been provided with a commit hash, however I have tried looking in Git if I can search using commit hashes but couldn't find anything.
Is there a way I can find the changed code just by using the commit hash?
git-clean - Remove untracked files from the working tree
Synopsis
git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>…Description
Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.
Normally, only files unknown to Git are removed, but if the
-xoption is specified, ignored files are also removed. This can, for example, be useful to remove all build products.If any optional
<path>...arguments are given, only those paths are affected.
Step 1 is to show what will be deleted by using the -n option:
# Print out the list of files and directories which will be removed (dry run)
git clean -n -d
Clean Step - beware: this will delete files:
# Delete the files from the repository
git clean -f
git clean -f -d or git clean -fdgit clean -f -X or git clean -fXgit clean -f -x or git clean -fxNote the case difference on the X for the two latter commands.
If clean.requireForce is set to "true" (the default) in your configuration, one needs to specify -f otherwise nothing will actually happen.
Again see the git-clean docs for more information.
Options
-f,--forceIf the Git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given
-f,-nor-i.
-xDon’t use the standard ignore rules read from .gitignore (per directory) and
$GIT_DIR/info/exclude, but do still use the ignore rules given with-eoptions. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build.
-XRemove only files ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files.
-n,--dry-runDon’t actually remove anything, just show what would be done.
-dRemove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use
-foption twice if you really want to remove such a directory.
git commit --amend
will open your editor, allowing you to change the commit message of the most recent commit. Additionally, you can set the commit message directly in the command line with:
git commit --amend -m "New commit message"
…however, this can make multi-line commit messages or small corrections more cumbersome to enter.
Make sure you don't have any working copy changes staged before doing this or they will get committed too. (Unstaged changes will not get committed.)
If you've already pushed your commit up to your remote branch, then - after amending your commit locally (as described above) - you'll also need to force push the commit with:
git push <remote> <branch> --force
# Or
git push <remote> <branch> -f
Warning: force-pushing will overwrite the remote branch with the state of your local one. If there are commits on the remote branch that you don't have in your local branch, you will lose those commits.
Warning: be cautious about amending commits that you have already shared with other people. Amending commits essentially rewrites them to have different SHA IDs, which poses a problem if other people have copies of the old commit that you've rewritten. Anyone who has a copy of the old commit will need to synchronize their work with your newly re-written commit, which can sometimes be difficult, so make sure you coordinate with others when attempting to rewrite shared commit history, or just avoid rewriting shared commits altogether.
Another option is to use interactive rebase. This allows you to edit any message you want to update even if it's not the latest message.
In order to do a Git squash, follow these steps:
// n is the number of commits up to the last commit you want to be able to edit
git rebase -i HEAD~n
Once you squash your commits - choose the e/r for editing the message:
When you use git rebase -i HEAD~n there can be more than n commits. Git will "collect" all the commits in the last n commits, and if there was a merge somewhere in between that range you will see all the commits as well, so the outcome will be n + .
If you have to do it for more than a single branch and you might face conflicts when amending the content, set up git rerere and let Git resolve those conflicts automatically for you.
Best Answer
A URL of the form
https://github.com/<owner>/<project>/commit/<hash>will show you the changes introduced in that commit. For example here's a recent bugfix I made to one of my projects on GitHub:https://github.com/jerith666/git-graph/commit/35e32b6a00dec02ae7d7c45c6b7106779a124685
You can also shorten the hash to any unique prefix, like so:
https://github.com/jerith666/git-graph/commit/35e32b
I know you just asked about GitHub, but for completeness: If you have the repository checked out, from the command line, you can achieve basically the same thing with either of these commands (unique prefixes work here too):
Note: If you shorten the commit hash too far, the command line gives you a helpful disambiguation message, but GitHub will just return a 404.