diff --git a/.nojekyll b/.nojekyll
new file mode 100644
index 0000000..e69de29
diff --git a/01-introduction.html b/01-introduction.html
new file mode 100644
index 0000000..b85e894
--- /dev/null
+++ b/01-introduction.html
@@ -0,0 +1,572 @@
+
+Git for Official Statistics: Introduction
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
Identify uses and purposes for using Git in official statistics
+
+
+
+
+
+
Version Control in General
+
+
Version control is important whether you are working alone or
+collaboratively, even if you are not working in statistics!
+
Here’s the basics of how a version control system works:
+
start with a base version of a document
+
record changes made each step of the way
+
collaborators can add changes in independently without conflict
+
You’ve probably already seen a version control system.
+
Good version control systems will allow you to see the history of a
+project and will sync across different computers, facilitating
+collaboration.
+
+
+
+
+
+
Version Control Systems
+
+
+
What version control systems have you likely already come across?
+List 1-2
+
+
+
+
+
+
+
+
+
You’ve probably seen Microsoft’s Track Changes and Google Doc’s
+version history
+
+
+
+
+
Why Version Controlling Matters in Official Statistics
+
+
There are a number of reasons why version control matters matters in
+official statistics:
+
Reproducibility: Within and across organizations, we need to be
+able to reproduce statistics. This could be to ensure consistency in
+methodology across reference periods, or check to see if statistics are
+comparable in their methodologies.
+
Standardization: We can use version control systems as a single
+source of truth to create standardization of statistics between and
+within organizations.
+
Disseminate changes and updated versions: Following our single
+source of truth, we can easily update and share changes to calculations
+of official statistics as well as any new documentation or
+methodologies. This means we are updating in one place rather than
+many.
+
Collaboration: Version control systems allow us to collaborate
+and connect on the creation of official statistics internally and
+externally with stakeholders. We can use these systems to share proposed
+changes, share work, and test code.
+
Efficient and Effective Development of Code: With a single source
+of truth, we know exactly where to propose and find changes code that
+makes our statistics. In addition, many version control systems have
+project management or feedback tools that we can leverage to bundle
+communication and discussion with the code itself rather than working in
+multiple systems. This can allow for faster feedback and proposed
+updates.
+
+
diff --git a/02-version_control.html b/02-version_control.html
new file mode 100644
index 0000000..a59c250
--- /dev/null
+++ b/02-version_control.html
@@ -0,0 +1,518 @@
+
+Git for Official Statistics: Version Control
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
diff --git a/03-git_setup.html b/03-git_setup.html
new file mode 100644
index 0000000..f85429a
--- /dev/null
+++ b/03-git_setup.html
@@ -0,0 +1,693 @@
+
+Git for Official Statistics: Setting up Git
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
Before we start using Git for the first time on a new computer, there
+are some things we need to set up. In this lesson, we will:
+
Add a name and email address
+
Set the text editor used for writing commit messages
+
Understand the difference between --global and
+--local configuration
+
View/confirm configuration settings
+
We will be using Git Bash, the command line interface for Git.
+
Configure Name and Email
+
+
An important first step in using Git is adding your name and email.
+This information will be attached to commits,
+branches,
+and other changes you make in the future. This identifiability and
+accountability for code changes is one of the key benefits to using
+Git.
+
At the Git Bash prompt, enter the following, substituting your full
+name for the name in quotation marks after user.name and
+your email for the email address following user.email.
Your situation may vary, but if you are writing code in your official
+capacity and using an agency repository, you will most likely want to
+use your official email address and the one associated with your account
+on GitHub, GitLab, or other code sharing site.
+
Configure Text Editor
+
+
+
This is optional. By default, Git Bash will use the Vim text
+editor.
+
+
There are many different Git clients and ways of interacting with Git
+on your computer. Some clients have a full user interface that you use
+for selecting files to stage for commits and authoring commit messages.
+Others, like Git Bash, have a command line interface so when you want to
+write a lengthy commit message, it needs to call up a text editor.
+
+
+
+
+
+
Different Ways to Author Commit Messages
+
+
+
As you will learn in a
+later lesson, once you make updates to your code, you will want to
+make a snapshot of those updates called a commit and provide an
+informative message that describes what was changed. This message can be
+short and be written on the command line (e.g.,
+git commit -m "Update README.md"). Sometimes however, you
+will want to write a longer, multi-line commit message. You can do this
+by entering git commit on the command line. This will bring
+up the text editor you have configured as your default.
+
+
+
+
The default text editor for Git Bash is Vim which has a reputation
+for being difficult, especially for new users. So you may want to change
+to something easier to use or something you are more familiar with
+(e.g., your favorite text editor).
+
To switch to one of the following editors in the tables below, you
+can use the associated configuration commands.
+
The nano text editor is packaged with Git Bash and Notepad is
+included in the Windows operating system.
The text editors below are not available by default, but you may be
+available to you. Setup for these is more complex because it requires
+providing a filepath to the program executable which may not be the same
+for everyone.
$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"
+
VS Code
+
$ git config --global core.editor "code --wait"
+
If you ever want to switch back to Vim as the default, you can run
+the following command.
+
Editor
+
Configuration command
+
Vim
+
$ git config --global core.editor "vim"
+
+
+
+
+
+
Exiting Vim
+
+
+
Vim is surprisingly difficult to exit from. If you wish to exit a
+session without saving your changes, press Esc then type
+:q! and hit Enter or ↵. If you want
+to save your changes and quit, press Esc then type
+:wq and hit Enter or ↵.
+
+
+
+
+--global vs. --local
+
+
In the code samples above, we have used the --global
+flag. These are the settings Git will use for all repositories on your
+computer. As your use of Git becomes more complex, you may wish to have
+different configuration settings for different repositories. This is
+when you might use the --local flag. --local
+allows you to set configuration for specific repositories.
+
To set local configuration, open Git Bash and navigate to the
+repository you want to configure. You can then use the commands above,
+but substitute --local for --global.
+
For example, if you want to set a different name or email address for
+a specific project, you can do so with commands like those below.
These settings will override the --global configuration
+settings for that repository only.
+
View/Confirm Configuration
+
+
You may wish to check your configuration settings.
+
To see all configuration settings, you can use the following command.
+If you are in a repository, this will show all global and local
+configuration settings.
+
+
BASH
+
+
$ git config --list
+
+
To view global settings only (Note: This command can be run
+anywhere):
+
+
BASH
+
+
$ git config --global--list
+
+
To view local settings only (Note: This has to be run while
+in a repository):
+
+
BASH
+
+
$ git config --local--list
+
+
To view specific settings, include the setting name. For example, to
+view the email address configuration setting:
+
+
BASH
+
+
$ git config user.email
+
+
Other Configuration Settings
+
+
There are other, optional configuration settings you may wish to
+change. Review Git documentation and consult with others on your team
+about other settings.
+
+
+
+
+
+
Key Points
+
+
+
Use git config with the --global option to
+configure a user name, email address, editor, and other preferences once
+per machine.
+
Use --local in place of --global within a
+repository to set repository specific changes.
+
+
diff --git a/04-create_repo.html b/04-create_repo.html
new file mode 100644
index 0000000..b4fc42f
--- /dev/null
+++ b/04-create_repo.html
@@ -0,0 +1,515 @@
+
+Git for Official Statistics: Creating a Repository
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
First let’s make sure we’re still in the right directory. You should
+be in the planets directory.
+
+
BASH
+
+
$ cd ~/Desktop/planets
+
+
Let’s create a file called mars.txt that contains some
+notes about the Red Planet’s suitability as a base. We’ll use
+nano to edit the file; you can use whatever editor you
+like. In particular, this does not have to be the
+core.editor you set globally earlier. But remember, the
+bash command to create or edit a new file will depend on the editor you
+choose (it might not be nano). For a refresher on text
+editors, check out “Which
+Editor?” in The Unix Shell
+lesson.
+
+
BASH
+
+
$ nano mars.txt
+
+
Type the text below into the mars.txt file:
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+
+
Let’s first verify that the file was properly created by running the
+list command (ls):
+
+
BASH
+
+
$ ls
+
+
+
OUTPUT
+
+
mars.txt
+
+
mars.txt contains a single line, which we can see by
+running:
+
+
BASH
+
+
$ cat mars.txt
+
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+
+
If we check the status of our project again, Git tells us that it’s
+noticed the new file:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+
+No commits yet
+
+Untracked files:
+ (use "git add <file>..." to include in what will be committed)
+
+ mars.txt
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+
The “untracked files” message means that there’s a file in the
+directory that Git isn’t keeping track of. We can tell Git to track a
+file using git add:
+
+
BASH
+
+
$ git add mars.txt
+
+
and then check that the right thing happened:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+
+No commits yet
+
+Changes to be committed:
+ (use "git rm --cached <file>..." to unstage)
+
+ new file: mars.txt
+
+
+
Git now knows that it’s supposed to keep track of
+mars.txt, but it hasn’t recorded these changes as a commit
+yet. To get it to do that, we need to run one more command:
+
+
BASH
+
+
$ git commit -m"Start notes on Mars as a base"
+
+
+
OUTPUT
+
+
[main (root-commit) f22b25e] Start notes on Mars as a base
+ 1 file changed, 1 insertion(+)
+ create mode 100644 mars.txt
+
+
When we run git commit, Git takes everything we have
+told it to save by using git add and stores a copy
+permanently inside the special .git directory. This
+permanent copy is called a commit
+(or revision) and its short
+identifier is f22b25e. Your commit may have another
+identifier.
+
We use the -m flag (for “message”) to record a short,
+descriptive, and specific comment that will help us remember later on
+what we did and why. If we just run git commit without the
+-m option, Git will launch nano (or whatever
+other editor we configured as core.editor) so that we can
+write a longer message.
+
[Good commit messages][commit-messages] start with a brief (<50
+characters) statement about the changes made in the commit. Generally,
+the message should complete the sentence “If applied, this commit will”
+. If you want to go into more detail, add a blank
+line between the summary line and your additional notes. Use this
+additional space to explain why you made changes and/or what their
+impact will be.
+
If we run git status now:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+nothing to commit, working tree clean
+
+
it tells us everything is up to date. If we want to know what we’ve
+done recently, we can ask Git to show us the project’s history using
+git log:
+
+
BASH
+
+
$ git log
+
+
+
OUTPUT
+
+
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 09:51:46 2013 -0400
+
+ Start notes on Mars as a base
+
+
git log lists all commits made to a repository in
+reverse chronological order. The listing for each commit includes the
+commit’s full identifier (which starts with the same characters as the
+short identifier printed by the git commit command
+earlier), the commit’s author, when it was created, and the log message
+Git was given when the commit was created.
+
+
+
+
+
+
Where Are My Changes?
+
+
+
If we run ls at this point, we will still see just one
+file called mars.txt. That’s because Git saves information
+about files’ history in the special .git directory
+mentioned earlier so that our filesystem doesn’t become cluttered (and
+so that we can’t accidentally edit or delete an old version).
+
+
+
+
Now suppose Dracula adds more information to the file. (Again, we’ll
+edit with nano and then cat the file to show
+its contents; you may use a different editor, and don’t need to
+cat.)
+
+
BASH
+
+
$ nano mars.txt
+$ cat mars.txt
+
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+
+
When we run git status now, it tells us that a file it
+already knows about has been modified:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+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: mars.txt
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
The last line is the key phrase: “no changes added to commit”. We
+have changed this file, but we haven’t told Git we will want to save
+those changes (which we do with git add) nor have we saved
+them (which we do with git commit). So let’s do that now.
+It is good practice to always review our changes before saving them. We
+do this using git diff. This shows us the differences
+between the current state of the file and the most recently saved
+version:
+
+
BASH
+
+
$ git diff
+
+
+
OUTPUT
+
+
diff --git a/mars.txt b/mars.txt
+index df0654a..315bf3a 100644
+--- a/mars.txt
++++ b/mars.txt
+@@ -1 +1,2 @@
+ Cold and dry, but everything is my favorite color
++The two moons may be a problem for Wolfman
+
+
The output is cryptic because it is actually a series of commands for
+tools like editors and patch telling them how to
+reconstruct one file given the other. If we break it down into
+pieces:
+
The first line tells us that Git is producing output similar to the
+Unix diff command comparing the old and new versions of the
+file.
+
The second line tells exactly which versions of the file Git is
+comparing; df0654a and 315bf3a are unique
+computer-generated labels for those versions.
+
The third and fourth lines once again show the name of the file
+being changed.
+
The remaining lines are the most interesting, they show us the
+actual differences and the lines on which they occur. In particular, the
++ marker in the first column shows where we added a
+line.
+
After reviewing our change, it’s time to commit it:
+
+
BASH
+
+
$ git commit -m"Add concerns about effects of Mars' moons on Wolfman"
+
+
+
OUTPUT
+
+
On branch main
+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: mars.txt
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
Whoops: Git won’t commit because we didn’t use git add
+first. Let’s fix that:
+
+
BASH
+
+
$ git add mars.txt
+$ git commit -m"Add concerns about effects of Mars' moons on Wolfman"
+
+
+
OUTPUT
+
+
[main 34961b1] Add concerns about effects of Mars' moons on Wolfman
+ 1 file changed, 1 insertion(+)
+
+
Git insists that we add files to the set we want to commit before
+actually committing anything. This allows us to commit our changes in
+stages and capture changes in logical portions rather than only large
+batches. For example, suppose we’re adding a few citations to relevant
+research to our thesis. We might want to commit those additions, and the
+corresponding bibliography entries, but not commit some of our
+work drafting the conclusion (which we haven’t finished yet).
+
To allow for this, Git has a special staging area where it
+keeps track of things that have been added to the current changeset but not yet committed.
+
+
+
+
+
+
Staging Area
+
+
+
If you think of Git as taking snapshots of changes over the life of a
+project, git add specifies what will go in a
+snapshot (putting things in the staging area), and
+git commit then actually takes the snapshot, and
+makes a permanent record of it (as a commit). If you don’t have anything
+staged when you type git commit, Git will prompt you to use
+git commit -a or git commit --all, which is
+kind of like gathering everyone to take a group photo! However,
+it’s almost always better to explicitly add things to the staging area,
+because you might commit changes you forgot you made. (Going back to the
+group photo simile, you might get an extra with incomplete makeup
+walking on the stage for the picture because you used
+-a!).
+
In the context of creating official statistics, using
+--all or -a can lead to files being staged and
+committed that should not be released (like microdata) or can cause
+difficulties for others on the project (like environment files).
+
Staging things manually or using a pattern is the best practice,
+otherwise you might find yourself searching for “git undo commit” more
+than you would like!
+
Remember to use git status after you add files to check
+what you have staged/added.
+
+
+
+
Let’s watch as our changes to a file move from our editor to the
+staging area and into long-term storage. First, we’ll add another line
+to the file:
+
+
BASH
+
+
$ nano mars.txt
+$ cat mars.txt
+
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
+
+
+
BASH
+
+
$ git diff
+
+
+
OUTPUT
+
+
diff --git a/mars.txt b/mars.txt
+index 315bf3a..b36abfd 100644
+--- a/mars.txt
++++ b/mars.txt
+@@ -1,2 +1,3 @@
+ Cold and dry, but everything is my favorite color
+ The two moons may be a problem for Wolfman
++But the Mummy will appreciate the lack of humidity
+
+
So far, so good: we’ve added one line to the end of the file (shown
+with a + in the first column). Now let’s put that change in
+the staging area and see what git diff reports:
+
+
BASH
+
+
$ git add mars.txt
+$ git diff
+
+
There is no output: as far as Git can tell, there’s no difference
+between what it’s been asked to save permanently and what’s currently in
+the directory. However, if we do this:
+
+
BASH
+
+
$ git diff --staged
+
+
+
OUTPUT
+
+
diff --git a/mars.txt b/mars.txt
+index 315bf3a..b36abfd 100644
+--- a/mars.txt
++++ b/mars.txt
+@@ -1,2 +1,3 @@
+ Cold and dry, but everything is my favorite color
+ The two moons may be a problem for Wolfman
++But the Mummy will appreciate the lack of humidity
+
+
it shows us the difference between the last committed change and
+what’s in the staging area. Let’s save our changes:
+
+
BASH
+
+
$ git commit -m"Discuss concerns about Mars' climate for Mummy"
+
+
+
OUTPUT
+
+
[main 005937f] Discuss concerns about Mars' climate for Mummy
+ 1 file changed, 1 insertion(+)
+
+
check our status:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+nothing to commit, working tree clean
+
+
and look at the history of what we’ve done so far:
+
+
BASH
+
+
$ git log
+
+
+
OUTPUT
+
+
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 10:14:07 2013 -0400
+
+ Discuss concerns about Mars' climate for Mummy
+
+commit 34961b159c27df3b475cfe4415d94a6d1fcd064d
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 10:07:21 2013 -0400
+
+ Add concerns about effects of Mars' moons on Wolfman
+
+commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 09:51:46 2013 -0400
+
+ Start notes on Mars as a base
+
+
+
+
+
+
+
Word-based diffing
+
+
+
Sometimes, e.g. in the case of the text documents a line-wise diff is
+too coarse. That is where the --color-words option of
+git diff comes in very useful as it highlights the changed
+words using colors.
+
+
+
+
+
+
+
+
+
Paging the Log
+
+
+
When the output of git log is too long to fit in your
+screen, git uses a program to split it into pages of the
+size of your screen. When this “pager” is called, you will notice that
+the last line in your screen is a :, instead of your usual
+prompt.
+
To get out of the pager, press Q.
+
To move to the next page, press Spacebar.
+
To search for some_word in all pages, press
+/ and type some_word. Navigate through matches
+pressing N.
+
+
+
+
+
+
+
+
+
Limit Log Size
+
+
+
To avoid having git log cover your entire terminal
+screen, you can limit the number of commits that Git lists by using
+-N, where N is the number of commits that you
+want to view. For example, if you only want information from the last
+commit you can use:
+
+
BASH
+
+
$ git log -1
+
+
+
OUTPUT
+
+
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 10:14:07 2013 -0400
+
+ Discuss concerns about Mars' climate for Mummy
+
+
You can also reduce the quantity of information using the
+--oneline option:
+
+
BASH
+
+
$ git log --oneline
+
+
+
OUTPUT
+
+
005937f (HEAD -> main) Discuss concerns about Mars' climate for Mummy
+34961b1 Add concerns about effects of Mars' moons on Wolfman
+f22b25e Start notes on Mars as a base
+
+
You can also combine the --oneline option with others.
+One useful combination adds --graph to display the commit
+history as a text-based graph and to indicate which commits are
+associated with the current HEAD, the current branch
+main, or [other Git references][git-references]:
+
+
BASH
+
+
$ git log --oneline--graph
+
+
+
OUTPUT
+
+
* 005937f (HEAD -> main) Discuss concerns about Mars' climate for Mummy
+* 34961b1 Add concerns about effects of Mars' moons on Wolfman
+* f22b25e Start notes on Mars as a base
+
+
+
+
+
+
+
+
+
+
Directories
+
+
+
Two important facts you should know about directories in Git.
+
Git does not track directories on their own, only files within them.
+Try it for yourself:
+
+
BASH
+
+
$ mkdir spaceships
+$ git status
+$ git add spaceships
+$ git status
+
+
Note, our newly created empty directory spaceships does
+not appear in the list of untracked files even if we explicitly add it
+(viagit add) to our repository. This is the
+reason why you will sometimes see .gitkeep files in
+otherwise empty directories. Unlike .gitignore, these files
+are not special and their sole purpose is to populate a directory so
+that Git adds it to the repository. In fact, you can name such files
+anything you like.
+
If you create a directory in your Git repository and populate it
+with files, you can add all files in the directory at once by:
+
+
BASH
+
+
git add <directory-with-files>
+
+
Try it for yourself:
+
+
BASH
+
+
$ touch spaceships/apollo-11 spaceships/sputnik-1
+$ git status
+$ git add spaceships
+$ git status
+
+
Before moving on, we will commit these changes.
+
+
BASH
+
+
$ git commit -m"Add some initial thoughts on spaceships"
+
+
+
+
+
To recap, when we want to add changes to our repository, we first
+need to add the changed files to the staging area (git add)
+and then commit the staged changes to the repository
+(git commit):
+
+
+
+
+
+
Choosing a Commit Message
+
+
+
Which of the following commit messages would be most appropriate for
+the last commit made to mars.txt?
+
“Changes”
+
“Added line ‘But the Mummy will appreciate the lack of humidity’ to
+mars.txt”
+
“Discuss effects of Mars’ climate on the Mummy”
+
+
+
+
+
+
+
+
+
Answer 1 is not descriptive enough, and the purpose of the commit is
+unclear; and answer 2 is redundant to using “git diff” to see what
+changed in this commit; but answer 3 is good: short, descriptive, and
+imperative.
+
+
+
+
+
+
+
+
+
+
Committing Changes to Git
+
+
+
Which command(s) below would save the changes of
+myfile.txt to my local Git repository?
Modify the file as described (modify one line, add a fourth line). To
+display the differences between its updated state and its original
+state, use git diff:
+
+
diff --git a/06-exploring_history.html b/06-exploring_history.html
new file mode 100644
index 0000000..428c7d6
--- /dev/null
+++ b/06-exploring_history.html
@@ -0,0 +1,518 @@
+
+Git for Official Statistics: Exploring History
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
diff --git a/07-ignoring_things.html b/07-ignoring_things.html
new file mode 100644
index 0000000..a3ce36e
--- /dev/null
+++ b/07-ignoring_things.html
@@ -0,0 +1,517 @@
+
+Git for Official Statistics: Ignoring Things
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
diff --git a/08-remotes.html b/08-remotes.html
new file mode 100644
index 0000000..173c3d5
--- /dev/null
+++ b/08-remotes.html
@@ -0,0 +1,515 @@
+
+Git for Official Statistics: Remotes in GitLab/GitHub
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
diff --git a/11-working_remotes.html b/11-working_remotes.html
new file mode 100644
index 0000000..2e63821
--- /dev/null
+++ b/11-working_remotes.html
@@ -0,0 +1,518 @@
+
+Git for Official Statistics: Working with Others in GitHub/GitLab
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
diff --git a/12-documentation.html b/12-documentation.html
new file mode 100644
index 0000000..40568d5
--- /dev/null
+++ b/12-documentation.html
@@ -0,0 +1,518 @@
+
+Git for Official Statistics: Documenting in GitHub/GitLab for official statistics
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Git for Official Statistics
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Documenting in GitHub/GitLab for official statistics
+
+
diff --git a/404.html b/404.html
new file mode 100644
index 0000000..ea010ff
--- /dev/null
+++ b/404.html
@@ -0,0 +1,478 @@
+
+Git for Official Statistics: Page not found
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Git for Official Statistics
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Page not found
+
+
Our apologies!
+
+
We cannot seem to find the page you are looking for. Here are some
+tips that may help:
+
+
diff --git a/CODE_OF_CONDUCT.html b/CODE_OF_CONDUCT.html
new file mode 100644
index 0000000..8cbe311
--- /dev/null
+++ b/CODE_OF_CONDUCT.html
@@ -0,0 +1,483 @@
+
+Git for Official Statistics: Contributor Code of Conduct
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-Alpha
+
+ This lesson is in the pre-alpha phase, which means that it is in early development, but has not yet been taught.
+
+
+
+
to Share—copy and redistribute the material in any
+medium or format
+
to Adapt—remix, transform, and build upon the
+material
+
for any purpose, even commercially.
+
The licensor cannot revoke these freedoms as long as you follow the
+license terms.
+
Under the following terms:
+
Attribution—You must give appropriate credit
+(mentioning that your work is derived from work that is Copyright (c)
+The Carpentries and, where practical, linking to https://carpentries.org/), provide a link to the
+license, and indicate if changes were made. You may do so in any
+reasonable manner, but not in any way that suggests the licensor
+endorses you or your use.
+
No additional restrictions—You may not apply
+legal terms or technological measures that legally restrict others from
+doing anything the license permits. With the understanding
+that:
+
Notices:
+
You do not have to comply with the license for elements of the
+material in the public domain or where your use is permitted by an
+applicable exception or limitation.
+
No warranties are given. The license may not give you all of the
+permissions necessary for your intended use. For example, other rights
+such as publicity, privacy, or moral rights may limit how you use the
+material.
+
Software
+
+
Except where otherwise noted, the example programs and other software
+provided by The Carpentries are made available under the OSI-approved MIT
+license.
+
Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+“Software”), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
Trademark
+
+
“The Carpentries”, “Software Carpentry”, “Data Carpentry”, and
+“Library Carpentry” and their respective logos are registered trademarks
+of Community Initiatives.
Identify uses and purposes for using Git in official statistics
+
+
+
+
+
+
+
Version Control in General
+
+
+
+
Version control is important whether you are working alone or
+collaboratively, even if you are not working in statistics!
+
Here’s the basics of how a version control system works:
+
+
start with a base version of a document
+
record changes made each step of the way
+
collaborators can add changes in independently without conflict
+
+
You’ve probably already seen a version control system.
+
Good version control systems will allow you to see the history of a
+project and will sync across different computers, facilitating
+collaboration.
+
+
+
+
+
+
Version Control Systems
+
+
+
What version control systems have you likely already come across?
+List 1-2
+
+
+
+
+
+
+
+
+
You’ve probably seen Microsoft’s Track Changes and Google Doc’s
+version history
+
+
+
+
+
Why Version Controlling Matters in Official Statistics
+
+
+
+
There are a number of reasons why version control matters matters in
+official statistics:
+
+
Reproducibility: Within and across organizations, we need to be
+able to reproduce statistics. This could be to ensure consistency in
+methodology across reference periods, or check to see if statistics are
+comparable in their methodologies.
+
Standardization: We can use version control systems as a single
+source of truth to create standardization of statistics between and
+within organizations.
+
Disseminate changes and updated versions: Following our single
+source of truth, we can easily update and share changes to calculations
+of official statistics as well as any new documentation or
+methodologies. This means we are updating in one place rather than
+many.
+
Collaboration: Version control systems allow us to collaborate
+and connect on the creation of official statistics internally and
+externally with stakeholders. We can use these systems to share proposed
+changes, share work, and test code.
+
Efficient and Effective Development of Code: With a single source
+of truth, we know exactly where to propose and find changes code that
+makes our statistics. In addition, many version control systems have
+project management or feedback tools that we can leverage to bundle
+communication and discussion with the code itself rather than working in
+multiple systems. This can allow for faster feedback and proposed
+updates.
Before we start using Git for the first time on a new computer, there
+are some things we need to set up. In this lesson, we will:
+
+
Add a name and email address
+
Set the text editor used for writing commit messages
+
Understand the difference between --global and
+--local configuration
+
View/confirm configuration settings
+
+
We will be using Git Bash, the command line interface for Git.
+
Configure Name and Email
+
+
+
+
An important first step in using Git is adding your name and email.
+This information will be attached to commits,
+branches,
+and other changes you make in the future. This identifiability and
+accountability for code changes is one of the key benefits to using
+Git.
+
At the Git Bash prompt, enter the following, substituting your full
+name for the name in quotation marks after user.name and
+your email for the email address following user.email.
Your situation may vary, but if you are writing code in your official
+capacity and using an agency repository, you will most likely want to
+use your official email address and the one associated with your account
+on GitHub, GitLab, or other code sharing site.
+
Configure Text Editor
+
+
+
+
+
This is optional. By default, Git Bash will use the Vim text
+editor.
+
+
There are many different Git clients and ways of interacting with Git
+on your computer. Some clients have a full user interface that you use
+for selecting files to stage for commits and authoring commit messages.
+Others, like Git Bash, have a command line interface so when you want to
+write a lengthy commit message, it needs to call up a text editor.
+
+
+
+
+
+
Different Ways to Author Commit Messages
+
+
+
As you will learn in a
+later lesson, once you make updates to your code, you will want to
+make a snapshot of those updates called a commit and provide an
+informative message that describes what was changed. This message can be
+short and be written on the command line (e.g.,
+git commit -m "Update README.md"). Sometimes however, you
+will want to write a longer, multi-line commit message. You can do this
+by entering git commit on the command line. This will bring
+up the text editor you have configured as your default.
+
+
+
+
The default text editor for Git Bash is Vim which has a reputation
+for being difficult, especially for new users. So you may want to change
+to something easier to use or something you are more familiar with
+(e.g., your favorite text editor).
+
To switch to one of the following editors in the tables below, you
+can use the associated configuration commands.
+
The nano text editor is packaged with Git Bash and Notepad is
+included in the Windows operating system.
The text editors below are not available by default, but you may be
+available to you. Setup for these is more complex because it requires
+providing a filepath to the program executable which may not be the same
+for everyone.
$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"
+
+
+
VS Code
+
$ git config --global core.editor "code --wait"
+
+
+
+
If you ever want to switch back to Vim as the default, you can run
+the following command.
+
+
+
+
+
+
+
Editor
+
Configuration command
+
+
+
Vim
+
$ git config --global core.editor "vim"
+
+
+
+
+
+
+
+
Exiting Vim
+
+
+
Vim is surprisingly difficult to exit from. If you wish to exit a
+session without saving your changes, press Esc then type
+:q! and hit Enter or ↵. If you want
+to save your changes and quit, press Esc then type
+:wq and hit Enter or ↵.
+
+
+
+
+--global vs. --local
+
+
+
+
In the code samples above, we have used the --global
+flag. These are the settings Git will use for all repositories on your
+computer. As your use of Git becomes more complex, you may wish to have
+different configuration settings for different repositories. This is
+when you might use the --local flag. --local
+allows you to set configuration for specific repositories.
+
To set local configuration, open Git Bash and navigate to the
+repository you want to configure. You can then use the commands above,
+but substitute --local for --global.
+
For example, if you want to set a different name or email address for
+a specific project, you can do so with commands like those below.
These settings will override the --global configuration
+settings for that repository only.
+
View/Confirm Configuration
+
+
+
+
You may wish to check your configuration settings.
+
To see all configuration settings, you can use the following command.
+If you are in a repository, this will show all global and local
+configuration settings.
+
+
BASH
+
+
$ git config --list
+
+
To view global settings only (Note: This command can be run
+anywhere):
+
+
BASH
+
+
$ git config --global--list
+
+
To view local settings only (Note: This has to be run while
+in a repository):
+
+
BASH
+
+
$ git config --local--list
+
+
To view specific settings, include the setting name. For example, to
+view the email address configuration setting:
+
+
BASH
+
+
$ git config user.email
+
+
Other Configuration Settings
+
+
+
+
There are other, optional configuration settings you may wish to
+change. Review Git documentation and consult with others on your team
+about other settings.
+
+
+
+
+
+
Key Points
+
+
+
+
Use git config with the --global option to
+configure a user name, email address, editor, and other preferences once
+per machine.
+
Use --local in place of --global within a
+repository to set repository specific changes.
First let’s make sure we’re still in the right directory. You should
+be in the planets directory.
+
+
BASH
+
+
$ cd ~/Desktop/planets
+
+
Let’s create a file called mars.txt that contains some
+notes about the Red Planet’s suitability as a base. We’ll use
+nano to edit the file; you can use whatever editor you
+like. In particular, this does not have to be the
+core.editor you set globally earlier. But remember, the
+bash command to create or edit a new file will depend on the editor you
+choose (it might not be nano). For a refresher on text
+editors, check out “Which
+Editor?” in The Unix Shell
+lesson.
+
+
BASH
+
+
$ nano mars.txt
+
+
Type the text below into the mars.txt file:
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+
+
Let’s first verify that the file was properly created by running the
+list command (ls):
+
+
BASH
+
+
$ ls
+
+
+
OUTPUT
+
+
mars.txt
+
+
mars.txt contains a single line, which we can see by
+running:
+
+
BASH
+
+
$ cat mars.txt
+
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+
+
If we check the status of our project again, Git tells us that it’s
+noticed the new file:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+
+No commits yet
+
+Untracked files:
+ (use "git add <file>..." to include in what will be committed)
+
+ mars.txt
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+
The “untracked files” message means that there’s a file in the
+directory that Git isn’t keeping track of. We can tell Git to track a
+file using git add:
+
+
BASH
+
+
$ git add mars.txt
+
+
and then check that the right thing happened:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+
+No commits yet
+
+Changes to be committed:
+ (use "git rm --cached <file>..." to unstage)
+
+ new file: mars.txt
+
+
+
Git now knows that it’s supposed to keep track of
+mars.txt, but it hasn’t recorded these changes as a commit
+yet. To get it to do that, we need to run one more command:
+
+
BASH
+
+
$ git commit -m"Start notes on Mars as a base"
+
+
+
OUTPUT
+
+
[main (root-commit) f22b25e] Start notes on Mars as a base
+ 1 file changed, 1 insertion(+)
+ create mode 100644 mars.txt
+
+
When we run git commit, Git takes everything we have
+told it to save by using git add and stores a copy
+permanently inside the special .git directory. This
+permanent copy is called a commit
+(or revision) and its short
+identifier is f22b25e. Your commit may have another
+identifier.
+
We use the -m flag (for “message”) to record a short,
+descriptive, and specific comment that will help us remember later on
+what we did and why. If we just run git commit without the
+-m option, Git will launch nano (or whatever
+other editor we configured as core.editor) so that we can
+write a longer message.
+
[Good commit messages][commit-messages] start with a brief (<50
+characters) statement about the changes made in the commit. Generally,
+the message should complete the sentence “If applied, this commit will”
+. If you want to go into more detail, add a blank
+line between the summary line and your additional notes. Use this
+additional space to explain why you made changes and/or what their
+impact will be.
+
If we run git status now:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+nothing to commit, working tree clean
+
+
it tells us everything is up to date. If we want to know what we’ve
+done recently, we can ask Git to show us the project’s history using
+git log:
+
+
BASH
+
+
$ git log
+
+
+
OUTPUT
+
+
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 09:51:46 2013 -0400
+
+ Start notes on Mars as a base
+
+
git log lists all commits made to a repository in
+reverse chronological order. The listing for each commit includes the
+commit’s full identifier (which starts with the same characters as the
+short identifier printed by the git commit command
+earlier), the commit’s author, when it was created, and the log message
+Git was given when the commit was created.
+
+
+
+
+
+
Where Are My Changes?
+
+
+
If we run ls at this point, we will still see just one
+file called mars.txt. That’s because Git saves information
+about files’ history in the special .git directory
+mentioned earlier so that our filesystem doesn’t become cluttered (and
+so that we can’t accidentally edit or delete an old version).
+
+
+
+
Now suppose Dracula adds more information to the file. (Again, we’ll
+edit with nano and then cat the file to show
+its contents; you may use a different editor, and don’t need to
+cat.)
+
+
BASH
+
+
$ nano mars.txt
+$ cat mars.txt
+
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+
+
When we run git status now, it tells us that a file it
+already knows about has been modified:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+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: mars.txt
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
The last line is the key phrase: “no changes added to commit”. We
+have changed this file, but we haven’t told Git we will want to save
+those changes (which we do with git add) nor have we saved
+them (which we do with git commit). So let’s do that now.
+It is good practice to always review our changes before saving them. We
+do this using git diff. This shows us the differences
+between the current state of the file and the most recently saved
+version:
+
+
BASH
+
+
$ git diff
+
+
+
OUTPUT
+
+
diff --git a/mars.txt b/mars.txt
+index df0654a..315bf3a 100644
+--- a/mars.txt
++++ b/mars.txt
+@@ -1 +1,2 @@
+ Cold and dry, but everything is my favorite color
++The two moons may be a problem for Wolfman
+
+
The output is cryptic because it is actually a series of commands for
+tools like editors and patch telling them how to
+reconstruct one file given the other. If we break it down into
+pieces:
+
+
The first line tells us that Git is producing output similar to the
+Unix diff command comparing the old and new versions of the
+file.
+
The second line tells exactly which versions of the file Git is
+comparing; df0654a and 315bf3a are unique
+computer-generated labels for those versions.
+
The third and fourth lines once again show the name of the file
+being changed.
+
The remaining lines are the most interesting, they show us the
+actual differences and the lines on which they occur. In particular, the
++ marker in the first column shows where we added a
+line.
+
+
After reviewing our change, it’s time to commit it:
+
+
BASH
+
+
$ git commit -m"Add concerns about effects of Mars' moons on Wolfman"
+
+
+
OUTPUT
+
+
On branch main
+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: mars.txt
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
Whoops: Git won’t commit because we didn’t use git add
+first. Let’s fix that:
+
+
BASH
+
+
$ git add mars.txt
+$ git commit -m"Add concerns about effects of Mars' moons on Wolfman"
+
+
+
OUTPUT
+
+
[main 34961b1] Add concerns about effects of Mars' moons on Wolfman
+ 1 file changed, 1 insertion(+)
+
+
Git insists that we add files to the set we want to commit before
+actually committing anything. This allows us to commit our changes in
+stages and capture changes in logical portions rather than only large
+batches. For example, suppose we’re adding a few citations to relevant
+research to our thesis. We might want to commit those additions, and the
+corresponding bibliography entries, but not commit some of our
+work drafting the conclusion (which we haven’t finished yet).
+
To allow for this, Git has a special staging area where it
+keeps track of things that have been added to the current changeset but not yet committed.
+
+
+
+
+
+
Staging Area
+
+
+
If you think of Git as taking snapshots of changes over the life of a
+project, git add specifies what will go in a
+snapshot (putting things in the staging area), and
+git commit then actually takes the snapshot, and
+makes a permanent record of it (as a commit). If you don’t have anything
+staged when you type git commit, Git will prompt you to use
+git commit -a or git commit --all, which is
+kind of like gathering everyone to take a group photo! However,
+it’s almost always better to explicitly add things to the staging area,
+because you might commit changes you forgot you made. (Going back to the
+group photo simile, you might get an extra with incomplete makeup
+walking on the stage for the picture because you used
+-a!).
+
In the context of creating official statistics, using
+--all or -a can lead to files being staged and
+committed that should not be released (like microdata) or can cause
+difficulties for others on the project (like environment files).
+
Staging things manually or using a pattern is the best practice,
+otherwise you might find yourself searching for “git undo commit” more
+than you would like!
+
Remember to use git status after you add files to check
+what you have staged/added.
+
+
+
+
Let’s watch as our changes to a file move from our editor to the
+staging area and into long-term storage. First, we’ll add another line
+to the file:
+
+
BASH
+
+
$ nano mars.txt
+$ cat mars.txt
+
+
+
OUTPUT
+
+
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
+
+
+
BASH
+
+
$ git diff
+
+
+
OUTPUT
+
+
diff --git a/mars.txt b/mars.txt
+index 315bf3a..b36abfd 100644
+--- a/mars.txt
++++ b/mars.txt
+@@ -1,2 +1,3 @@
+ Cold and dry, but everything is my favorite color
+ The two moons may be a problem for Wolfman
++But the Mummy will appreciate the lack of humidity
+
+
So far, so good: we’ve added one line to the end of the file (shown
+with a + in the first column). Now let’s put that change in
+the staging area and see what git diff reports:
+
+
BASH
+
+
$ git add mars.txt
+$ git diff
+
+
There is no output: as far as Git can tell, there’s no difference
+between what it’s been asked to save permanently and what’s currently in
+the directory. However, if we do this:
+
+
BASH
+
+
$ git diff --staged
+
+
+
OUTPUT
+
+
diff --git a/mars.txt b/mars.txt
+index 315bf3a..b36abfd 100644
+--- a/mars.txt
++++ b/mars.txt
+@@ -1,2 +1,3 @@
+ Cold and dry, but everything is my favorite color
+ The two moons may be a problem for Wolfman
++But the Mummy will appreciate the lack of humidity
+
+
it shows us the difference between the last committed change and
+what’s in the staging area. Let’s save our changes:
+
+
BASH
+
+
$ git commit -m"Discuss concerns about Mars' climate for Mummy"
+
+
+
OUTPUT
+
+
[main 005937f] Discuss concerns about Mars' climate for Mummy
+ 1 file changed, 1 insertion(+)
+
+
check our status:
+
+
BASH
+
+
$ git status
+
+
+
OUTPUT
+
+
On branch main
+nothing to commit, working tree clean
+
+
and look at the history of what we’ve done so far:
+
+
BASH
+
+
$ git log
+
+
+
OUTPUT
+
+
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 10:14:07 2013 -0400
+
+ Discuss concerns about Mars' climate for Mummy
+
+commit 34961b159c27df3b475cfe4415d94a6d1fcd064d
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 10:07:21 2013 -0400
+
+ Add concerns about effects of Mars' moons on Wolfman
+
+commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 09:51:46 2013 -0400
+
+ Start notes on Mars as a base
+
+
+
+
+
+
+
Word-based diffing
+
+
+
Sometimes, e.g. in the case of the text documents a line-wise diff is
+too coarse. That is where the --color-words option of
+git diff comes in very useful as it highlights the changed
+words using colors.
+
+
+
+
+
+
+
+
+
Paging the Log
+
+
+
When the output of git log is too long to fit in your
+screen, git uses a program to split it into pages of the
+size of your screen. When this “pager” is called, you will notice that
+the last line in your screen is a :, instead of your usual
+prompt.
+
+
To get out of the pager, press Q.
+
To move to the next page, press Spacebar.
+
To search for some_word in all pages, press
+/ and type some_word. Navigate through matches
+pressing N.
+
+
+
+
+
+
+
+
+
+
Limit Log Size
+
+
+
To avoid having git log cover your entire terminal
+screen, you can limit the number of commits that Git lists by using
+-N, where N is the number of commits that you
+want to view. For example, if you only want information from the last
+commit you can use:
+
+
BASH
+
+
$ git log -1
+
+
+
OUTPUT
+
+
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
+Author: Vlad Dracula <vlad@tran.sylvan.ia>
+Date: Thu Aug 22 10:14:07 2013 -0400
+
+ Discuss concerns about Mars' climate for Mummy
+
+
You can also reduce the quantity of information using the
+--oneline option:
+
+
BASH
+
+
$ git log --oneline
+
+
+
OUTPUT
+
+
005937f (HEAD -> main) Discuss concerns about Mars' climate for Mummy
+34961b1 Add concerns about effects of Mars' moons on Wolfman
+f22b25e Start notes on Mars as a base
+
+
You can also combine the --oneline option with others.
+One useful combination adds --graph to display the commit
+history as a text-based graph and to indicate which commits are
+associated with the current HEAD, the current branch
+main, or [other Git references][git-references]:
+
+
BASH
+
+
$ git log --oneline--graph
+
+
+
OUTPUT
+
+
* 005937f (HEAD -> main) Discuss concerns about Mars' climate for Mummy
+* 34961b1 Add concerns about effects of Mars' moons on Wolfman
+* f22b25e Start notes on Mars as a base
+
+
+
+
+
+
+
+
+
+
Directories
+
+
+
Two important facts you should know about directories in Git.
+
+
Git does not track directories on their own, only files within them.
+Try it for yourself:
+
+
+
BASH
+
+
$ mkdir spaceships
+$ git status
+$ git add spaceships
+$ git status
+
+
Note, our newly created empty directory spaceships does
+not appear in the list of untracked files even if we explicitly add it
+(viagit add) to our repository. This is the
+reason why you will sometimes see .gitkeep files in
+otherwise empty directories. Unlike .gitignore, these files
+are not special and their sole purpose is to populate a directory so
+that Git adds it to the repository. In fact, you can name such files
+anything you like.
+
+
If you create a directory in your Git repository and populate it
+with files, you can add all files in the directory at once by:
+
+
+
BASH
+
+
git add <directory-with-files>
+
+
Try it for yourself:
+
+
BASH
+
+
$ touch spaceships/apollo-11 spaceships/sputnik-1
+$ git status
+$ git add spaceships
+$ git status
+
+
Before moving on, we will commit these changes.
+
+
BASH
+
+
$ git commit -m"Add some initial thoughts on spaceships"
+
+
+
+
+
To recap, when we want to add changes to our repository, we first
+need to add the changed files to the staging area (git add)
+and then commit the staged changes to the repository
+(git commit):
+
+
+
+
+
+
Choosing a Commit Message
+
+
+
Which of the following commit messages would be most appropriate for
+the last commit made to mars.txt?
+
+
“Changes”
+
“Added line ‘But the Mummy will appreciate the lack of humidity’ to
+mars.txt”
+
“Discuss effects of Mars’ climate on the Mummy”
+
+
+
+
+
+
+
+
+
+
Answer 1 is not descriptive enough, and the purpose of the commit is
+unclear; and answer 2 is redundant to using “git diff” to see what
+changed in this commit; but answer 3 is good: short, descriptive, and
+imperative.
+
+
+
+
+
+
+
+
+
+
Committing Changes to Git
+
+
+
Which command(s) below would save the changes of
+myfile.txt to my local Git repository?
Modify the file as described (modify one line, add a fourth line). To
+display the differences between its updated state and its original
+state, use git diff:
