Changes

=Git Walkthrough: Basics=

We want to record every change we make to our files. This includes adding new files, making changes to those files, but also renaming, moving, and deleting. Every action we make with our code is something we want to record in git, something we want to be able to go back and examine or maybe undo. Git makes it easy to do all of this, by adding its own versions of common Unix file commands:* <code>git mv</code> - move or rename a file or directory* <code>git rm</code> - remove files from the working directory and index Let's try them both. First, we'll delete a file, then examine our repo's status: <pre>$ git rm CHANGELOG.mdrm 'CHANGELOG.md'$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage)  deleted: CHANGELOG.md</pre>  Here we've '''staged''' a delete, but we still have to '''commit''' it, just like when we '''add''' a file: <pre>$ git commit -m "Remove CHANGELOG"[master 7c16e80] Remove CHANGELOG 1 file changed, 5 deletions(-) delete mode 100755 CHANGELOG.md</pre> The file is now removed from our working directory, and a snapshot of our code without that file has been added to the history. The file still exists in the older snapshots, if we ever want to get it back (see below). If you need to recursively remove files under a directory, you can pass the <code>-r</code> (i.e., Recursive) flag: <pre>$ git commit -m "Rename LICENSE"[master 437bd08] Rename LICENSE 1 file changed, 0 insertions(+), 0 deletions(-) rename LICENSE => LICENSE.txt (100%)$ git rm -r dist/rm 'dist/css/bootstrap-grid.css'rm 'dist/css/bootstrap-grid.css.map'rm 'dist/css/bootstrap-grid.min.css'rm 'dist/css/bootstrap-grid.min.css.map'rm 'dist/css/bootstrap-reboot.css'rm 'dist/css/bootstrap-reboot.css.map'rm 'dist/css/bootstrap-reboot.min.css'rm 'dist/css/bootstrap-reboot.min.css.map'rm 'dist/css/bootstrap.css'rm 'dist/css/bootstrap.css.map'rm 'dist/css/bootstrap.min.css'rm 'dist/css/bootstrap.min.css.map'rm 'dist/js/bootstrap.js'rm 'dist/js/bootstrap.min.js'$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage)  deleted: dist/css/bootstrap-grid.css deleted: dist/css/bootstrap-grid.css.map deleted: dist/css/bootstrap-grid.min.css deleted: dist/css/bootstrap-grid.min.css.map deleted: dist/css/bootstrap-reboot.css deleted: dist/css/bootstrap-reboot.css.map deleted: dist/css/bootstrap-reboot.min.css deleted: dist/css/bootstrap-reboot.min.css.map deleted: dist/css/bootstrap.css deleted: dist/css/bootstrap.css.map deleted: dist/css/bootstrap.min.css deleted: dist/css/bootstrap.min.css.map deleted: dist/js/bootstrap.js deleted: dist/js/bootstrap.min.js $ git commit -m "Delete dist/"[master 6ec7cbc] Delete dist/ 14 files changed, 14668 deletions(-) delete mode 100755 dist/css/bootstrap-grid.css delete mode 100755 dist/css/bootstrap-grid.css.map delete mode 100755 dist/css/bootstrap-grid.min.css delete mode 100755 dist/css/bootstrap-grid.min.css.map delete mode 100755 dist/css/bootstrap-reboot.css delete mode 100755 dist/css/bootstrap-reboot.css.map delete mode 100755 dist/css/bootstrap-reboot.min.css delete mode 100755 dist/css/bootstrap-reboot.min.css.map delete mode 100755 dist/css/bootstrap.css delete mode 100755 dist/css/bootstrap.css.map delete mode 100755 dist/css/bootstrap.min.css delete mode 100755 dist/css/bootstrap.min.css.map delete mode 100755 dist/js/bootstrap.js delete mode 100755 dist/js/bootstrap.min.js</pre> Moving and renaming a file are just as easy, and both use the <code>git mv</code> command. Let's add a <code>.txt</code> extension to the <code>LICENSE</code> file, and commit the change: <pre>$ git mv LICENSE LICENSE.txt$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage)  renamed: LICENSE -> LICENSE.txt$ git commit -m "Rename LICENSE"[master 437bd08] Rename LICENSE 1 file changed, 0 insertions(+), 0 deletions(-) rename LICENSE => LICENSE.txt (100%)</pre> 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? We can '''amend''' our previous commit instead of making a new one easily. Let's see it in action. First, let's make a change to <code>docs/_includes/callout-warning-color-assistive-technologies.md</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.</pre>| <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.</pre>|} We can stage this change and commit: <pre>$ git statusOn branch masterChanges not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)  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, 5 insertions(+), 5 deletions(-) rewrite docs/_includes/callout-warning-color-assistive-technologies.md (84%)</pre> 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</code> file in your editor, and correct the second '''color''' to '''colour'''. Then we can add and re-commit: <pre>$ git add docs/_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, 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 statusOn branch masterChanges not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)  modified: CONTRIBUTING.md modified: README.md no changes added to commit (use "git add" and/or "git commit -a")$ git diffdiff --git a/CONTRIBUTING.md b/CONTRIBUTING.mdindex a0745d7..ffcd657 100755--- a/CONTRIBUTING.md+++ b/CONTRIBUTING.md@@ -7,7 +7,7 @@ process easy and effective for everyone involved.  Following these guidelines helps to communicate that you respect the time of 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 a/README.md b/README.mdindex a8a2c26..27f324b 100755--- a/README.md+++ b/README.md@@ -12,7 +12,7 @@  [](https://saucelabs.com/u/bootstrap) -Bootstrap is a sleek, intuitive, 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 a fun, intuitive, 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.  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 masterChanges 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 -- <file>..." to discard changes in working directory)  modified: CONTRIBUTING.md</pre> My changes to <code>CONTRIBUTING.md</code> are still present in my working directory, but they are no longer '''staged''' as part of this commit. I could go one step further and ask git to "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 checkout -- CONTRIBUTING.md$ git statusOn branch masterChanges to be committed: (use "git reset 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.

* Client Server (SVN) and Distributed (In the [[DPS909 & OSD600 Winter 2017 - Git)* Snapshots vs. versioned files.** Walkthrough 2 | second git walk- ** Checksums, SHA-1 ([http://www.miraclesalad.com/webtools/sha1.php try onlinethrough]])** Starting a Git Repo:*** git init*** git clone** File States:*** Untracked (not known to git)*** Tracked: modified, staged, committed** The staging area* Basic Git Commands and Concepts** git help we''<command>''** git add** git commit, git commit -m, git commit -a** git rm** git mv** git status** git log** git diff, ll look at how git diff --staged** enables distributed workflows.gitignore** Branches*** HEAD, master*** git checkout, git checkout -b*** git branch, git branch -a, git branch -d, git branch --merged, git branch --contains*** git merge*** git rebase** Remotes*** origin, origin/''branch''*** git remote*** git remote add*** git fetch*** git pull*** git push** Github, Pull Requests