<pre>
$ git log
commit e189bada7f9e77e8717cada46fa7cd05d6103172
Author: David Humphrey (:humph) david.humphrey@senecacollege.ca <david.humphrey@senecacollege.ca>
Telling git about the changes to a file's name or path means that it can track changes to the file contents even when it moves (i.e., git will know that <code>LICENSE</code> and <code>LICENSE.txt</code> represent the same thing in the history)
===Step 7: fixing common mistakes===
A common issue we all run into is committing a change, then realizing we made a mistake or forgot to include a related change. It's fine to just commit again, but what if you made a typo in your commit message or left something out that really should have been included?
* Client Server (SVN) and Distributed (Git)* Snapshots vsWe can '''amend''' our previous commit instead of making a new one easily. versioned files Let's see it in action.** Walkthrough - ** ChecksumsFirst, SHA-1 ([http:let's make a change to <code>docs/_includes/wwwcallout-warning-color-assistive-technologies.miraclesaladmd</code>, which changes '''color''' to '''colour''': {| class="wikitable"! style="font-weight: bold;" | Before! style="font-weight: bold;" | After|-| <pre>{% callout warning %}#### Conveying meaning to assistive technologies Using color to add meaning only provides a visual indication, which will not be conveyed to users of assistive technologies – such as screen readers.com</webtoolspre>| <pre>{% callout warning %}#### Conveying meaning to assistive technologies Using colour to add meaning only provides a visual indication, which will not be conveyed to users of assistive technologies – such as screen readers.</sha1.php try online])pre>|} ** Starting a Git RepoWe can stage this change and commit:*** <pre>$ git initstatus*** git cloneOn branch master** File StatesChanges not staged for commit:*** Untracked (not known use "git add <file>..." to update what will be committed) (use "gitcheckout -- <file>..." to discard changes in working directory)*** Tracked modified: modified docs/_includes/callout-warning-color-assistive-technologies.md no changes added to commit (use "git add" and/or "git commit -a")$ git add docs/_includes/callout-warning-color-assistive-technologies.md$ git commit -m "Switch color to colour in docs/_includes/callout-warning-color-assistive-technologies.md"[master 1e9d17d] Switch color to colour in docs/_includes/callout-warning-color-assistive-technologies.md 1 file changed, staged5 insertions(+), committed5 deletions(-) rewrite docs/_includes/callout-warning-color-assistive-technologies.md (84%)** The staging area</pre>* Basic Git Commands and Concepts** git help Later we discover that there are actually 2 occurances of '''color'''in that file, and we only changed the first one. Let's fix that and alter our commit using the <code>--amend</code> flag. First, re-open the <code>docs/_includes/callout-warning-color-assistive-technologies.md<command/code>file in your editor, and correct the second '''color''' to '''colour'''. Then we can add and re-commit:** <pre>$ git adddocs/_includes/callout-warning-color-assistive-technologies.md** $ git commit--amend --no-edit</pre> NOTE: you can also use this method to fix a typo in your commit message, just leave off the <code>--no-edit</code> flag. Doing so will cause git to open your editor and let you edit your previous commit message. If you like it as is, just save the file and exit. After amending my commit -m, I can <code>git show</code> the commit and prove to myself that both uses of '''color''' have in fact been changed: <pre>commit 88f1a8976d7d7d6a031d1e8fe9c212a5a357650eAuthor: David Humphrey (:humph) david.humphrey@senecacollege.ca <david.humphrey@senecacollege.ca>Date: Wed Jan 11 16:14:17 2017 -0500 Switch color to colour in docs/_includes/callout-warning-color-assistive-technologies.md diff --git a/docs/_includes/callout-warning-color-assistive-technologies.md b/docs/_includes/callout-warning-color-assistive-technologies.mdindex b92a1c3..c1a4533 100755--- a/docs/_includes/callout-warning-color-assistive-technologies.md+++ b/docs/_includes/callout-warning-color-assistive-technologies.md@@ -1,5 +1,5 @@ {% callout warning %} #### Conveying meaning to assistive technologies -Using color to add meaning only provides a visual indication, which will not be conveyed to users of assistive technologies – such as screen readers. Ensure that information denoted by the color is either obvious from the content itself (e.g. the visible text), or is included through alternative means, such as additional text hidden with the `.sr-only` class.+Using colour to add meaning only provides a visual indication, which will not be conveyed to users of assistive technologies – such as screen readers. Ensure that information denoted by the colour is either obvious from the content itself (e.g. the visible text), or is included through alternative means, such as additional text hidden with the `.sr-only` class. {% endcallout %}\ No newline at end of file</pre> Another common scenario that happens is accidentally staging changes to files that you didn't mean to add. For example, you might be testing a fix you've made, and need to hard-code a filename in another file to see if it works. Once you know it's working, you want to commit the fix but not your testing code. People often get into this problem when they add too much at once, for example <code>git add ** </code>. This will work, but it adds '''everything''' that's different in your working directory. Let's modify two files, <code>CONTRIBUTING.md</code> and <code>README.md</code>. I've made two small modifications, replacing one word in each file. Here's my repo's status and diff: <pre>$ git rmstatus** On branch masterChanges not staged for commit: (use "git mvadd <file>..." to update what will be committed)** (use "git statuscheckout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md modified: README.md ** no changes added to commit (use "git add" and/or "git logcommit -a")** $ git diff, git diff --stagedgit a/CONTRIBUTING.md b/CONTRIBUTING.mdindex a0745d7..ffcd657 100755** --- a/CONTRIBUTING.gitignoremd** Branches+++ b/CONTRIBUTING.md*** HEAD@@ -7,7 +7, master7 @@ process easy and effective for everyone involved. Following these guidelines helps to communicate that you respect the time of*** git checkout the developers managing and developing this open source project. In return, -they should reciprocate that respect in addressing your issue or assessing+they should reciprocate that respect in addressing your issue or reviewing patches and features. diff --git checkout a/README.md b/README.mdindex a8a2c26..27f324b 100755---a/README.md+++ b/README.md@@ -12,7 +12,7 @@*** git branch [](https://saucelabs.com/u/bootstrap) -Bootstrap is a sleek, intuitive, git branch and powerful front-end framework for faster and easier web development, created by [Mark Otto](https://twitter.com/mdo) and [Jacob Thornton](https://twitter.com/fat), and maintained by the [core team](https://github.com/orgs/twbs/people) with the massive support and involvement of the community.+Bootstrap is afun, intuitive, git branch and powerful front-dend framework for faster and easier web development, created by [Mark Otto](https://twitter.com/mdo) and [Jacob Thornton](https://twitter.com/fat), and maintained by the [core team](https://github.com/orgs/twbs/people) with the massive support and involvement of the community. To get started, check out <https://getbootstrap.com>!</pre> Let's "accidentally" add all changed files at once (i.e., use <code>*</code> instead of individual filenames): <pre>$ git add *$ git statusOn branch --mergedmasterChanges to be committed: (use "git reset HEAD <file>..." to unstage) modified: CONTRIBUTING.md modified: README.md</pre> What if I didn't mean to include the change to <code>CONTRIBUTING.md</code> in this commit? Git helpfully tells me what to do: <code>use "git reset HEAD <file>..." to unstage</code>. This means to reset what you have in the staging area for the given file with what was in the last commit (the <code>HEAD</code>), essentially undoing your last staged changes. Let's try it! <pre>$ git reset HEAD CONTRIBUTING.mdUnstaged changes after reset:M CONTRIBUTING.md$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage) modified: README.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout --contains<file>..." to discard changes in working directory) *** git merge modified: CONTRIBUTING.md*** git rebase</pre>** Remotes*** originMy changes to <code>CONTRIBUTING.md</code> are still present in my working directory, origin/but they are no longer '''staged'branch''as part of this commit.*** I could go one step further and ask git remoteto "undo" all changes to <code>CONTRIBUTING.md</code> in my working directory. This is more destructive than what we did above, since it means rewriting the file exactly as it was in the last commit. But, when you want to get back to a known-good state, it's an easy way to correct things. <pre>*** $ git remote addcheckout -- CONTRIBUTING.md*** $ git fetchstatusOn branch masterChanges to be committed:*** (use "git pullreset HEAD <file>..." to unstage) modified: README.md</pre> Now the changes I made to <code>CONTRIBUTING.md</code> are gone, and the last-known version of that file is what is in my working directory once more. *** In the [[DPS909 & OSD600 Winter 2017 - Git Walkthrough 2 | second git push** Githubwalk-through]], Pull Requestswe'll look at how git enables distributed workflows.
