These exercises aim to give you some practice with using the Git version control system.<\/strong><\/p>\n\n\n\n Each exercise comes in two parts: a main task that most, if not all, course attendees should be able to complete in the allocated time, as well as a stretch task for those who complete the main task quickly<\/strong><\/p>\n\n\n\n Main Task<\/strong> Stretch Task<\/strong> Related – Git basic local workflow These exercises aim to give you some practice with using the Git version control system. Each exercise comes in two parts:… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-30798","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/30798","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=30798"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/30798\/revisions"}],"predecessor-version":[{"id":30799,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/30798\/revisions\/30799"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=30798"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=30798"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=30798"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
1. Create a new directory and change into it.
2. Use the init<\/strong> command to create a Git repository in that directory.
3. Observe that there is now a .git<\/strong> directory.
4. Create a README<\/strong> file.
5. Look at the output of the status<\/strong> command; the README<\/strong> you created should appear as an untracked file.
6. Use the add<\/strong> command to add the new file to the staging area. Again, look at the output of the status<\/strong> command.
7. Now use the commit<\/strong> command to commit the contents of the staging area.
8. Create a src<\/strong> directory and add a couple of files to it.
9. Use the add<\/strong> command, but name the directory, not the individual files. Use the status<\/strong> command. See how both files have been staged. Commit them.
10. Make a change to one of the files. Use the diff<\/strong> command to view the details of the change.
11. Next, add<\/strong> the changed file, and notice how it moves to the staging area in the status<\/strong> output. Also observe that the diff<\/strong> command you did before using add now gives no output. Why not? What do you have to do to see a diff<\/strong> of the things in the staging area? (Hint: review the slides if you can’t remember.)
12. Now without committing, make another change to the same file you changed in step 10. Look at the status<\/strong> output, and the diff<\/strong> output. Notice how you can have both staged and unstaged changes, even when you are talking about a single file. Observe the difference when you use the add<\/strong> command to stage the latest round of changes. Finally, commit<\/strong> them. You should now have started to get a feel for the staging area.
13. Use the log<\/strong> command in order to see all of the commits you made so far.
14. Use the show<\/strong> command to look at an individual commit. How many characters of the commit identifier can you get away with typing at a minimum?
15. Make a couple more commits, at least one of which should add an extra file.<\/p>\n\n\n\n
1. Use the Git rm command to remove a file. Look at the status<\/strong> afterwards. Now commit the deletion.
2. Delete another file, but this time do not use Git to do it; e.g. if you are on Linux, just use the normal (non-Git) rm<\/strong> command; on Windows use del<\/strong>.
3. Look at the status<\/strong>. Compare it to the status output you had after using the Git built-in rm command. Is anything different? After this, commit the deletion.
4. Use the Git mv command to move or rename a file; for example, rename README<\/strong> to README.txt<\/strong>. Look at the status. Commit the change.
5. Now do another rename, but this time using the operating system’s command to do so. How does the status look? Will you get the right outcome if you were to commit at this point? (Answer: almost certainly not, so do not. \ud83d\ude42 Work out how to get the status<\/strong> to show that it will not lose the file, and then commit. Did Git at any point work out that you had done a rename?
6. Use git help log<\/strong> to find out how to get Git to display just the most recent 3 commits. Try it.
7. If you do not remember, look back in the slides to see what the –stat<\/strong> option did on the diff<\/strong> command. Find out if this also works with the show command. How about the log<\/strong> command?
8. Imagine you want to see a diff<\/strong> that summarizes all that happened between two commit identifiers. Use the diff command, specifying two commit identifiers joined by two dots (that is, something like abc123..def456<\/strong>). Check the output is what you expect.<\/p>\n","protected":false},"excerpt":{"rendered":"