Git Started: Hands-On Git for Agile Writers Workshop STC Summit 2015
•
4 likes•820 views
During the production process, performing basic command line tasks can be vital for Agile writers. This workshop introduces the basics of using Git, a version-control software, to view in-production changes and update UI text. By performing these tasks on your own, you will save time and energy, ensure quality text in your product, and get mad technical props from your developers.
Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Recently uploaded
Recently uploaded (20)
Git Started: Hands-On Git for Agile Writers Workshop STC Summit 2015
- 1. Applications >> Utilities >> Terminal 3. Git should be available on the command line. Windows users, select “Use Git from the Windows Command Prompt” and then “Checkout Windows-‐ style, commit Unix-‐style” 2. Use the Git Setup Wizard to install Git. Go to http://www.git-‐scm.com/download/ and follow the instructions for your operating system. 1. Download Git’s binary installer. Before we get started… If you don’t already have it, install Git. If you have a GitHub account already, you’ll need to make sure you’re logged out, so you can use another account for the workshop! Let me know if you need help with that. Start >> Search “Command” >> Command Prompt" 4. Run two commands to set up your info in Git. @SarahKiniry #STC15 # git config —global user.email “your@email.address” git config —global user.name “Your Name”
- 2. GIT STARTED: Sarah Kiniry Technical Writer, cPanel, Inc. HANDS-ON GIT™ FOR AGILE WRITERS @SarahKiniry #STC15 #
- 3. What is Git? Lots of developers. One central repository. Use it for any (ALL) file types. @SarahKiniry #STC15 # Version Control Software
- 4. Version Control Software Simultaneous development by multiple teams. Everyone eventually merges to one canonical repository (or two… or three…) @SarahKiniry #STC15 #
- 5. Why should writers use git? @SarahKiniry #STC15 # $ Real time access to product changes. % & Increased transparency. Minimize the waterfall. ' Fewer bribes to get information.
- 6. Get on the COMMAND LINE @SarahKiniry #STC15 #
- 7. Navigate to Applications >> Utilities >> Terminal Get on the command line If you haven’t installed Git yet or made a GitHub account, your worksheet has instructions. Don’t panic! If you can’t install Git, you can still follow along! Click Start Search for “Command” Click on Command Prompt @SarahKiniry #STC15 # Mac " Windows
- 8. ~ $ Get on the command line @SarahKiniry #STC15 #
- 9. ~ $ Get on the command line @SarahKiniry #STC15 # The prompt.
- 10. ~ $ Get on the command line @SarahKiniry #STC15 # This part shows your current directory.
- 11. ~ $ Get on the command line @SarahKiniry #STC15 # Enter commands here. To run them, press Enter.
- 12. Step 1: CLONE THE REPO @SarahKiniry #STC15 #
- 13. Clone The Repository A database that contains all of the project’s (or team’s) revisions. ) * Each repository contains an object store (files, commits, etc.) and an index (how to structure it). Clone = copy to your local machine. + , - . 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 14. Clone the repository Cloning downloads all of the files in the STC2015 repository, and places them on the local computer in a new directory. ~ $ git clone https://github.com/sarahkiniry/STC2015.git ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 15. Clone the repository Cloning downloads all of the files in the STC2015 repository, and places them on the local computer in a new directory. ~ $ git clone https://github.com/sarahkiniry/STC2015.git Cloning into 'STC2015'... remote: Counting objects: 16, done. remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16 Unpacking objects: 100% (16/16), done. Checking connectivity... done ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 16. Navigate to the directory All of the work that you do in git has to happen in within the repository. Otherwise, git commands result in errors. ~ $ cd STC2015 ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 17. Navigate to the directory All of the work that you do in git has to happen in within the repository. Otherwise, git commands result in errors. ~ $ cd STC2015 STC2015 $ ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 18. Navigate to the directory All of the work that you do in git has to happen in within the repository. Otherwise, git commands result in errors. ~ $ cd STC2015 STC2015 $ ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** 1. CLONE & CREATE / 0 ○ 2 Now you’re in the “STC2015” directory on your computer. @SarahKiniry #STC15 #
- 19. Create A Branch Branches separate lines of development in each repository. ) * If a team has its own repository, each team member might have a branch. You can access team members’ branches and work in them collaboratively. 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 20. Create a new branch Git branch creates a new branch. For this workshop, use your name as the branch name. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git branch branchname 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 21. Create a new branch Git branch creates a new branch. For this workshop, use your name as the branch name. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git branch branchname Use your name as the branch name. 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 22. Check out the new branch Use the git checkout command to work in the new branch. Your local computer might have several branches from the same repository at the same time. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git checkout branchname 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 23. Check out the new branch Use the git checkout command to switch branches. Your local computer might have several branches from the same repository at the same time. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git checkout branchname Switched to branch 'branchname' 1. CLONE & CREATE / 0 ○ 2 @SarahKiniry #STC15 #
- 25. Edit your files! ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ vi index.html / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 # STC2015>notepad index.html Mac/Linux " Windows Windows
- 26. Edit your files! ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>STC 2015 Example Page</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> </head> <body> <img src="forkit.png" id="octocat" alt="The image goes here!" /> <!-- Hey, writers, ask me about this section! --> <p> / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 #
- 27. Edit your files! ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** In vim, use the arrows to find the text, and then hit i to go into text-edit mode. <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>STC 2015 Example Page</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> </head> <body> <img src="forkit.png" id="octocat" alt="The image goes here!" /> <!-- Hey, writers, ask me about this section! --> <p> Update the page title. / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 #
- 28. Edit your files! ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>THIS WORKSHOP IS AWESOME!</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> </head> <body> <img src="forkit.png" id="octocat" alt="The image goes here!" /> <!-- Hey, writers, ask me about this section! --> <p> Much better! After you change the text, save and close the file. In vim, hit ESC, type :wq to save and quit, and press enter. / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 #
- 29. Check your branch’s status ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git status The git status command shows you the full status of your local branch. / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 #
- 30. Check your branch’s status ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git status # On branch branchname # 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: index.html # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # .DS_Store no changes added to commit (use "git add" and/or "git commit -a") The git status command shows you the full status of your local branch. / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 #
- 31. Check your branch’s status ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git status # On branch branchname # 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: index.html # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # .DS_Store no changes added to commit (use "git add" and/or "git commit -a") The git status command shows you the full status of your local branch. The index.html file changed since the last commit. / 2. MAKE CHANGES 0 ○ 2 @SarahKiniry #STC15 #
- 33. Commit your changes 3 Commits package changes to go from your working directory to the central repository. 4 5 After you commit and push changes, others can access/update them. You choose what to stage for a commit - not everything has to go! + , - . / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 34. Add the file to the commit ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git add index.html Other commands will allow you to add all of the modified files at once — but if you only edited one or two files, this can be safer. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 35. Check your branch’s status ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git status The git status command shows you the full status of your local branch. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 36. Check your branch’s status ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git status # On branch branchname # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # .DS_Store The git status command shows you the full status of your local branch. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 37. Check your branch’s status ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git status # On branch branchname # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # .DS_Store The git status command shows you the full status of your local branch. Anything not in this list won’t go into your commit. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 38. Commit your changes ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git commit The commit packages up the new set of changes. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 39. Your commit message ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch branchname # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # index.html # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # .DS_Store Anything that isn’t commented out (#) in this file becomes the commit message in the log. (Editing in vim again? Hit i to type, then ESC and type :wq to save.) Enter it here. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 40. Commit your changes ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git commit [sarahkiniry 74880cf] More text changes. 1 file changed, 1 insertion(+), 1 deletion(-) After you save the commit message, you see your name, the new commit’s ID, the commit message, and some statistics about the commit. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 41. Push the commit ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git push https://github.com/sarahkiniry/STC2015.git branchname Pushing the commit sends all of your packaged-up changes to the central repository. After you push, anyone else can see your changes in the repo. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 42. Push the commit ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** Username for ‘https://github.com': gitstarted2015 Password for ‘https://github.com': stc2015 Pushing the commit sends all of your packaged-up changes to the central repository. After you push, anyone else can see your changes in the repo. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 43. Push the commit ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** Counting objects: 8, done. Delta compression using up to 8 threads. Compressing objects: 100% <3/3>, done. Writing objects: 100% <3/3>, 321 bytes : 0 bytes/s, done. Total 3 <delta 2>, reused 0 <delta 0> To https://github.com/sarahkiniry/STC2015.git * [new branch] branchname -> branchname You might see a “warning: push.default is unset” message if you’re on a brand- new installation of git and haven’t configured much yet. Your commit is still OK. / 0 3. COMMIT CHANGES ○ 2 @SarahKiniry #STC15 #
- 45. / 6 + git blame Tools to save your sanity git log git diff What changed? Who changed it? When? Why did they change it? Git allows you to be proactive during development… …even if your developers don’t have time to fill you in. @SarahKiniry #STC15 #
- 46. What’s different? The diff command compares files in your repository. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git diff b3c9f28..HEAD / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 47. Reading the diff The diff outputs line-by-line comparisons of every file that changed. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** diff --git a/anotherfile.txt b/anotherfile.txt new file mode 100644 index 0000000..3deee54 --- /dev/null +++ b/anotherfile.txt @@ -0,0 +1 @@ +This is some file contents. diff --git a/index.html b/index.html index e70b98a..5efb13d 100644 --- a/index.html +++ b/index.html @@ -3,7 +3,7 @@ <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> - <title>STC 2015 Example Page</title> + <title>THIS WORKSHOP IS AWESOME!</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 48. Reading the diff + and - indicate lines or other data that changed. How you format the command determines which commit gets which — it’s not chronological. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** diff --git a/anotherfile.txt b/anotherfile.txt new file mode 100644 index 0000000..3deee54 --- /dev/null +++ b/anotherfile.txt @@ -0,0 +1 @@ +This is some file contents. diff --git a/index.html b/index.html index e70b98a..5efb13d 100644 --- a/index.html +++ b/index.html @@ -3,7 +3,7 @@ <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> - <title>STC 2015 Example Page</title> + <title>THIS WORKSHOP IS AWESOME!</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> The anotherfile.txt file is new. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 49. Reading the diff + and - indicate lines or other data that changed. How you format the command determines which commit gets which — it’s not chronological. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** diff --git a/anotherfile.txt b/anotherfile.txt new file mode 100644 index 0000000..3deee54 --- /dev/null +++ b/anotherfile.txt @@ -0,0 +1 @@ +This is some file contents. diff --git a/index.html b/index.html index e70b98a..5efb13d 100644 --- a/index.html +++ b/index.html @@ -3,7 +3,7 @@ <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> - <title>STC 2015 Example Page</title> + <title>THIS WORKSHOP IS AWESOME!</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> The index.html file changed. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 50. Reading the diff + and - indicate lines or other data that changed. How you format the command determines which commit gets which — it’s not chronological. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** diff --git a/anotherfile.txt b/anotherfile.txt new file mode 100644 index 0000000..3deee54 --- /dev/null +++ b/anotherfile.txt @@ -0,0 +1 @@ +This is some file contents. diff --git a/index.html b/index.html index e70b98a..5efb13d 100644 --- a/index.html +++ b/index.html @@ -3,7 +3,7 @@ <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> - <title>STC 2015 Example Page</title> + <title>THIS WORKSHOP IS AWESOME!</title> <LINK href="styles.css" rel="stylesheet" type="text/css"> The page title for index.html changed. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 51. Who made this change? ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git blame index.html / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 52. Who made this change? Every line of git blame’s output includes the commit ID, committer, timestamp, and line number, and then the actual line in the file. ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 1) <!DOCTYPE html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 2) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 3) <html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 4) <head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 5) <meta http- equiv="Content-Type" content="text/html; charset=utf-8"/> b89234eb (Sarah Kiniry 2015-05-13 15:17:04 -0500 6) <title>THIS WORKSHOP IS AWESOME!</title> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 7) <LINK href="styles.css" rel="stylesheet" type="text/css"> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 8) </head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 9) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 10) <body> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 11) b3c9f28a (Sarah Kiniry 2015-03-09 17:06:00 -0500 12) <img src="forkit.png" / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 53. Who made this change? ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 1) <!DOCTYPE html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 2) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 3) <html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 4) <head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 5) <meta http- equiv="Content-Type" content="text/html; charset=utf-8"/> b89234eb (Sarah Kiniry 2015-05-13 15:17:04 -0500 6) <title>THIS WORKSHOP IS AWESOME!</title> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 7) <LINK href="styles.css" rel="stylesheet" type="text/css"> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 8) </head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 9) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 10) <body> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 11) b3c9f28a (Sarah Kiniry 2015-03-09 17:06:00 -0500 12) <img src="forkit.png" Every line of git blame’s output includes the commit ID, committer, timestamp, and line number, and then the actual line in the file. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 54. Who made this change? ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 1) <!DOCTYPE html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 2) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 3) <html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 4) <head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 5) <meta http- equiv="Content-Type" content="text/html; charset=utf-8"/> b89234eb (Sarah Kiniry 2015-05-13 15:17:04 -0500 6) <title>THIS WORKSHOP IS AWESOME!</title> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 7) <LINK href="styles.css" rel="stylesheet" type="text/css"> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 8) </head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 9) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 10) <body> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 11) b3c9f28a (Sarah Kiniry 2015-03-09 17:06:00 -0500 12) <img src="forkit.png" Every line of git blame’s output includes the commit ID, committer, timestamp, and line number, and then the actual line in the file. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 55. Who made this change? ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 1) <!DOCTYPE html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 2) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 3) <html> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 4) <head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 5) <meta http- equiv="Content-Type" content="text/html; charset=utf-8"/> b89234eb (Sarah Kiniry 2015-05-13 15:17:04 -0500 6) <title>THIS WORKSHOP IS AWESOME!</title> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 7) <LINK href="styles.css" rel="stylesheet" type="text/css"> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 8) </head> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 9) ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 10) <body> ^a30c19e (The Octocat 2014-02-04 14:38:24 -0800 11) b3c9f28a (Sarah Kiniry 2015-03-09 17:06:00 -0500 12) <img src="forkit.png" Every line of git blame’s output includes the commit ID, committer, timestamp, and line number, and then the actual line in the file. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 56. Check the commit log q ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** STC2015 $ git log dd53f326 -1 / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 57. Check the commit log ** These files were originally forked from GitHub’s octocat/Spoon-Knife repository.** Hopefully actual commit messages will be better than this one? STC2015 $ git log dd53f32 -1 Author: Sarah Kiniry <sarah.kiniry@cpanel.net> Date: Mon Mar 9 16:42:55 2015 -0500 Added some text and form items to the html page. / 0 ○ 4. ARCHAEOLOGY 2 @SarahKiniry #STC15 #
- 58. NOW WHAT? You used Git! @SarahKiniry #STC15 #
- 59. Become active on GitHub. Practice with Git. Learn “Hello World” Read the code first. Use Git often, and learn your company’s workflow for it.7 Start with the basics in every language your developers use. 8 Try to answer your own questions first — it’s a great way to learn.? Volunteer for a project… or just lurk and learn from watching.: What’s next? @SarahKiniry #STC15 #
- 60. GitHub has fantastic documentation/tutorials.: ; Resources There are lots of Git cheatsheets out there. 7 Git’s official website has excellent resources too. Git Version Control Cookbook Olsson/Voss Pro Git Scott Chacon *Read this one online for free! Version Control with Git Loeliger/McCullough Find more about these Git commands at technicolorwriter.com @SarahKiniry #STC15 #
Editor's Notes
- Welcome! This is Git Started: Hands-on Git for Agile Writers. Before we get started, I just want to make sure that everyone has Git installed on your computer - if you don’t, it should only take a minute or so. One of the two handouts each of you should have has the instructions to install Git and get on the command line to use it, and the other one is a cheat sheet of all of the commands that we’re going to be using this morning, just in case I get ahead of you a slide or two. If you’re more comfortable copy-pasting commands, you can also access this same information at technicolorwriter.com, and just click on “STC Summit 2015 Workshop Cheat Sheet” The “Agile” part of this workshop is referring to the fact that we’re going to look at using Git as part of Agile software development, as opposed to using it for actual documentation or website management. I’ll also be showing some archaeological tools in Git that are useful when you’re tracking down information for your Agile team.
- So, what is Git? Git is version control software. Version control software records not just the most up-to-date version of your files, but also the history of every change made, who made them, when, and other information. Git itself was designed for use by the team that develops the Linux kernel, so it’s great for software development, but it can be used with pretty much any project that’s stored as files, so it’s also popular for website management, document management, I even know someone who uses it for his grocery lists. The main point of Git, though, is that it allows a bunch of people to work on the same project at the same time, without a logistical nightmare.
- Git allows for many different workflow structures, so it can scale up in size as a project’s size or scope increases. One person can use it and benefit. One team. Many teams. Or combinations of many teams working together on many projects. It’s worth noting though that the really complex structures of this are going to require some advanced Git usage that goes far beyond anything we’re going to talk about today.
- Sounds great for developers, right? But why should technical communicators use Git to access project code? Real Time — You can see what’s going on, and make changes to interface/output text yourself — In a small way, you become a developer. Transparency — See every change that your team makes, whether they think it’s important for the writer to know about or not. Vett changes yourself — even the most well meaning team can miss the impact that a change has on documentation, especially if you write backend-centric or API documentation. Minimize the waterfall — A lot of the time, even on an Agile team, documentation can end up in a mini-waterfall. Seeing changes as they happen helps make sure that you’re writing before development is done. Fewer bribes and more developer goodwill — Spend your developer goodwill coins where you need them, and look AMAZING because you’ve already gleaned that “easy” information and are in the code with them asking informed questions.
- So, first, to use Git’s full functionality, you need to get on the command line. There are some graphical interfaces for Git — For example, the very-well-known GitHub, or Atlasssian’s Stash — but many of these don’t have the full functionality. Being able to use the graphical interfaces also depends on whether your team uses them — but as long as you can work from the command line, you should be able to handle most team setups. Don’t worry - if you don’t normally work on the command line it can be a little daunting, but it’s really pretty straightforward to do.
- This is also on your handout — here are the instructions to get to the command line for Mac or Windows computers. I’m assuming that if you’re fancy enough to use a non-standard operating system, you probably know how to get on the command line with it. Is anyone using a Chromebook? If you’re on a Chromebook, press CTRL+ALT+T to get to the command line.
- Once you’re on the command line, you’re going to see a screen that’s similar to this one. Every operating system is going to be a little different, especially when you factor in different configuration settings, so don’t be surprised if yours doesn’t look exactly like this.
- This is the command prompt, because it “prompts” you to enter and run commands.
- Most command prompts are going to indicate your working directory. Here, the tilde represents that I’m in the topmost or root directory of my computer.
- Most prompts are going to use a special character - often a dollar sign or a carat - to show where the area to enter commands begins. To run a command, it’s really simple. You’re just going to type the command in, and press Enter. Remember that spaces between parts of the command, and case, matters. You want to type things in exactly as they are on here or on your handouts.
- So now that everyone’s on the command line, the first step to start working in Git is to “clone” the main repository for the project that you’re working on.
- Before we do it, what does that mean? A repository is a database that contains all of a project’s Git information. So, it has every revision of the project. Every repository has two main parts: - The object store, which is all of the project’s files, commit messages, historical information. - The index, which is the information’s structure - what goes in which directory, that sort of information. In Git terminology, “clone” just means to copy the repository’s information to your local machine - your computer.
- “git clone” is the command to copy a repository. - The repository URL will generally use the .git extension. - In this case, we’re cloning a demo repository that I’ve doctored from a test repository that GitHub supplies.
- Assuming that the command runs correctly, you should see output that’s similar to this. Git creates a new subdirectory inside the current working directory (the directory that you were in when you ran the git clone command). That new directory is going to have the same name as the repository, so in this case it’s going to be STC2015.
- Git doesn’t automatically start you working in that new subdirectory for the repository, so you have to run a command to go inside it and start working in the Git repository. “cd” (which stands for “change directory”) is the command to use for both Mac or Windows, so you just type in cd, a space, and then the location that you want to go to, in this case STC2015.
- And as you can see, the command prompt is going to now reflect the change and show us that we’re in the STC2015 directory on the computer.
- Now that you’re working in the cloned repository, you need to create a new branch to hold your changes. A branch “branches” off from the main repository’s history, with new changes. Depending on how your team operates, each team member might work in their own branch, or you might all work in the same branches, with a separate branch for each change that you work on, maybe a branch for each user story if you’re using Agile development.
- The “git branch” command, followed by a unique branch name, creates a branch.
- I’ve used sarahkiniry as my branch name, but please use your own name, or something else that you’ll remember, for yours. Working on different projects, you might end up using a keyword for the project as a branch name, like “installerchanges”, or a case number if you use a case management system for bug fixes or changes.
- Like when you clone a repository, Git doesn’t automatically start you working in the branch that you just created. Use “git checkout” and the branch name to start working within that particular branch. Whenever you start to work in Git, you want to make sure you’re in the right branch. Branches of the same project are largely independent, unless you take steps to merge them, even though they contain similar files. “index.html” might be a file in two different branches, but changes in one aren’t inherently in the “index.html” file in another branch while both branches are being worked in.
- Once you use git checkout to switch branches, you’ll see a confirmation message.
- So now you’ve cloned a repository for the STC2015 project, and you’ve created and are working in a new branch of the project. The next step is to make some changes, which we’ll then send back (or “commit”) to the main repository. Generally, if you’re working with an Agile team, it’s MUCH easier to go in and update UI text or output messages yourself, rather than giving change notes to a developer to add. If nothing else, it’s going to prevent a game of telephone, and make sure that you get easily-missed things like oxford commas in there right where you want them.
- The way to open a file to edit it on the command line depends on your operating system, and on what’s installed on your computer. - Most Windows computers come with Notepad. When you run the command in Windows, it will automatically open the file in the Notepad program for you. You’ll be able to edit and save it just like you normally would in a text editor. - Most Apple computers come with Vim and Emacs. I prefer Vim, just because it’s what I used first, but that’s fighting words to some Emacs users. I’d suggest seeing which camp your team is in, and learning to use what they use first. Use the command here for your operating system, to open up the index.html file.
- The source code for index.html is going to open. Windows users, unfortunately it’s not going to play as nice with
- For this workshop, we just want to do a simple change, so let’s just update the header text - the text between the <title> tags. In vim, hit the letter i to go into “insert” mode. Then you can backspace out the text that’s there and replace it.
- Make sure not to remove or break the <title> tags around the text. In vim, when you’re done editing, hit Escape, and then type colon-w-q to save (“write”) and quit Vim, and then press Enter.
- When you save and exit your text editor program, you’ll be back on the command line with the command prompt. This step is optional, but if you’re like me I like to take advantage of every opportunity to make sure I haven’t broken anything! Enter and run “git status” to see a status report on the current branch that you’re working in. You can run this command just about anytime that you’re working in Git, to check in on how everything’s doing.
- Here’s the output for the git status command right now.
- As you can see, it’s showing us that index.html has been modified from how it was on the main repository.
- So now you want to take that change on your branch, and make it available for others on your team to view or update or work with. That means it’s time to make a “commit”.
- A “commit” sends changes from the working directory on your computer to the main repository that everyone can access. Before the changes move to the main repository, you add files that you want to send. This means that you only have to commit the changes that you choose to commit from your branch. That said, it’s a good idea to use separate branches, rather than selectively committing files, if your changes are unrelated.
- The “git add” command adds a file to the list of changes to commit. So, in this case, we only edited index.html so we’re only going to add that file to the commit. Windows users may see a warning about line endings - this is ok!
- “git add” doesn’t give any confirmation back, so if you want to check and make sure that you added the file correctly, you can run “git status” again to check.
- So here’s the branch’s current status…
- Everything that’s in the commit is now under “Changes to be committed” Modified files that you didn’t add to the commit would show up under a “Changes not staged to commit” header.
- So everything’s added to the commit that we want to add. Now you use the “git commit” command to package up all of those changes into a “commit”. This command is going to open up a blank commit message file in a text editor. For just about everyone, windows or Mac, this will be VIM.
- This is where you enter your commit log entry. Best practices would be to summarize WHAT you did, WHY you did it, HOW you did it, expected behavior, and testing steps. If you’re only doing text changes, the message probably won’t be that long, but that can mean pages of explanation on particularly large code commits. So, go ahead and enter a quick log entry for your commit. - Remember, in vim you want to hit i for insert mode, and then Escape + colon +wq to save and exit after you’re done.
- When you save and exit the file, you’ll see some basic information about your commit.
- So the commit is all packaged up now, with a log entry to explain the changes. Now you can send, or “push” it up to the main repository. The git push command does this. While you can set a default that Git will automatically push to, it’s often better to just specify where you want to push changes to each time. This is going to be the same URL that you used when you cloned the repository, and the branch name that you used to create your new branch.
- If this is your first time pushing anything to GitHub, it’s going to ask you for your username and password. Because GitHub requires me to grant permission to each account that’s pushing to this repository, I made a dummy account that everyone can use for this session. Enter each item as it asks for it, and press enter.
- This is showing that everything went well, and your new branch has been added!
- So, if all that you wanted to do with Git was make a few text changes, that would be it. If you’re an Agile writer who is also doing documentation, though, there are some really cool ways to get information out of Git.
- In a perfect world we’d all get all the info that we need from developers the moment that changes happen, but that’s not always the case. These three Git commands are only the tip of the iceberg, but they’re a great place to start. - git diff answers “What changed?” - git blame answers “Who changed it? When did they change it?” - git log answers “Why did they change it?” and hopefully gives you more information about the change.
- So, let’s say that it’s the day after you get back from the STC Summit, and you want to see what your teammates did while you were here in Columbus. If you know that the last commit that you saw had the commit ID (or SHA) of dd53f32, you can run the “git diff” command to show you everything that’s different since that commit. - After git diff and a space, you’re going to type in that commit ID - dd53f32, two periods, and then the word HEAD in all caps. Head is kind of like saying “Right now” - This is only ONE of the many ways that you can use git diff - you can also compare two branches, you can change the output to only compare a specific file, etc.
- Here’s the output for git diff… It’s worth noting that there were several commits between commit dd53f32 and the current status of things, but git diff is only giving me the summary of “here’s how it was then”/“here’s how it is now” without the fiddly bits. If something was added AND removed during that period, it’s going to add it up and get “no change there”.
- We can see that since we looked last, someone added a new image file. - Image files are only going to have summary information, since there’s no textual contents that would be worth outputting.
- And then we can see that the index.html file changed.
- The minus is going to appear next to the line as it appeared in the first commit that we specified to the git diff command. The plus sign is next to that same line as it appears in the second commit, which in this case was HEAD or “right now” If a bunch of new lines were added, you’d see several plus signs for the additions, and no minuses since no existing lines were changed. Make sense?
- So I know that something changed since I looked last. Now I want to know who changed it and what commit they did it in. “git blame” plus the changed file’s filename is going to show that information.
- So this is the same index.html file that we edited, but git blame has added information about the last time that each line was touched, before every line in the file. — Remember, this isn’t actually going to add this info TO the file, it’s just displaying it WITH the file
- It’s going to show the committer’s name. This is who to track down and ask about changes, if the commit log doesn’t answer the questions that you need answered.
- The time and date. This can be really useful if you’re tracking down information on an old change, maybe that slipped past documentation, or if you’re documenting something that was previously undocumented.
- The short form of the commit ID is going to be useful to pull up that commit’s information, including the log entry.
- “git log” plus a short commit ID lets you narrow in on a specific commit. So you’re going to use git log, a space, the commit ID which is b89234eb here, and then dash-1 to make sure that Git only shows the most recent commit that matches that ID.
- Here’s the commit log for that commit. So now hopefully the commit message will have the commit info that you need, OR you can go to the committer with questions and all of the facts already in hand that you gleaned from Git.
- So now that you’ve got the basics, what’s next?
- Use Git whenever you can, and learn your company’s methods — it’s so flexible that every team is going to use Git a little bit differently. Try to learn the basics of your company or team’s programming languages. For writers, this might mean that it’s more important to READ the code than to WRITE it. A great place to start is to learn what UI text or labels or other output looks like in that language, and then expand from there. If you can’t work with a team in Git, find a GitHub project to volunteer with, or you can just pick a project to lurk and watch.
- Finally, here’s some resources that you can check out. Pro Git is readable online for free! Git and GitHub are great resources for documentation and tutorials. And of course, my website is technicolorwriter.com, I’ve got posts about all of the things we’ve discussed in this workshop, and after this conference I’m planning a series on some more in-depth info on many of the commands that relate to Agile writers. QUESTIONS?