Otherwise, the diff will stop one commit early. This makes sure we diff down to the ancestor of that commit hash. So, everything in green is what will be added after reverting, and everything in red will be removed.Īlso note the ^ at the end there. Note this is from the perspective of changing from our most recent commit to the commit we're reverting to. Next, we see a line-by-line breakdown of lines added and removed from each modified file. In this case, the the resolution of a few images were updated. These files are often editor / build specific files (as in. First, we see a log of all binary files changed, with paths listed as a/file_path and b/file_path. To do so, use the copied hash and run the following command: git diff HEAD COPIED_HASH^ This is very vim so I don't blame you if you got stuck here □ Step 3: Diff against the most recent commitĬhecking for differences against your revert point is a great way to verify what changes you're about to make. Note: You can exit this log by hitting the "q" key. Once you find the inflection point for your code explosion, copy the hash for that commit and move on to the next step. These are hashes which uniquely identify a given commit. It also shows branch points to see the history of everything that got merged.Īlso notice the alphanumeric strings to the left of each commit. This will show all of the commit history for your branch, starting with the most recent. The cleanest way to do so is using: git log -oneline and out through the mouth.īefore doing anything you might regret, it's best to look through all recent commits to pinpoint where you're reverting to. Before frantically flying to the keyboard, just go in through the nose. The best way to overcome your escalating fear that your codebase / world is collapsing around you is deep breathing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |