What are the four different phases of
gitthat we’ve learned? What commands do you know to move changes from one phase to the next? Is there ever more than one way to move a change from one phase to another?
gitphases are the working directory, the staging area, the local repository, and the remote repository.
git add/git stagemoves changes from the working directory to the staging area (note both commands do the same thing).
git commitmoves changes from the staging area to the local repository
.git push` moves changes from the local repository to the remote repository.
What is the difference between
git statusdisplays changes in the working directory and staging area, whereas
git logdisplays the history of changes in the local repository.
What is the command to show the changes between our working directory and our staging area? How about between our staging area and the local repository?
git diffshows the changes between the working directory and the staging area.
git diff --stagedshows the changes between the staging area and the local repository.
Suppose you’re in a random directory on your computer and you want to check if it’s a
gitrepository. How might you check this, without using any
gitrepository is managed by the
.gitdirectory. So, to see if a given directory is a git repository, you could run
ls -aand see if a
As you grow more experienced with
gityou’ll find yourself typing a lot of long commands which can be cumbersome. Luckily for us,
gitallows to alias many of the commands we run so we can rename them. So, for example, let’s say we want to alias
st. If we wanted to do this for all
gitrepositories on our computer, we could typeOr, if we want to alias this for just the
git config --global alias.st status
gitrepository we’re currently using:Write your own global alias for
git config alias.st status
committhat makes sense for you!
This is an open ended question. Next week we’ll learn about
git checkout, but I think this command is really long and cumbersome. Therefore, I’ve aliased it globally to
git cowith the command
git config --global alias.co checkout.
The command we’re about to discuss can be very dangerous. Use this at your own risk, but it can be very useful if used correctly!
git resetcommand allows us to move changes out of a commit and back into the staging area. However, this command can be very dangerous if you’ve already pushed your changes to remote. Can you think of why this would cause problems? What might be a good rule of thumb for when to use something like
To understand the issue here we need to have a basic understanding of commits. Commits are uniquely identified by their hash, which is just a 40 character long string. If you run
git log, the long string you’ll see after
commit:is that commit’s hash. When you push, the remote repository tries to build the history by matching the hashes between the commit history that you pushed and the commit history it has saved.
Consider the following scenario, you have a local commit history which looks like this (the left number is the hash for that commit)Now, you push this to the remote repo. The history on remote now looks the same, i.e.
Local History abc123 Add file 2 dnekd2 Add file 1 fkdiek Initial commitNow imagine we run
Remote History abc123 Add file 2 dnekd2 Add file 1 fkdiek Initial commit
git reset, removing our most recent commit from the local history. We now make some more changes and add and commit them with the message
Add file 3. Now, our local history looks like this:Note that the hash of the new commit has changed, since hashes uniquely idetify each commit. Now, if we try to push this change our changes will be rejected, since the remote repository cannot determine which commit should follow
Local History lmnopq Add file 3 dnekd2 Add file 1 fkdiek Initial commit
Generally we want to avoid changing our commit history because it can cause problems like this. A good rule of thumb is that you should never modify any commits that have already been pushed to the remote repository.
One popular “version control” that you’ve probably used is Google Drive/Docs. How is this similar to git? How is it different?
As for similarities, both Google Drive and git are designed to facilitate collaboration (multiple people can work on the same project) and they keep track of changes made over time. They vary in the type content as google drive focuses on documents, spreadsheets, forms, etc. while git is used for source code and text-based files. Additionally, in git, users have to push or create merge requests to update a project (as they’ll have a copy of the project on their local machine), while in Google Drive, users can directly edit the project.
Using the man page, how would you undo (or revert) a commit. Is this what you expected? Why?
One way you can undo or revert a commit is through
git revert <commit-hash>, where the commit-hash refers to the most recent commit. What’s happening here is that we’re creating a new commit that undoes the changes introduced by a previous commit.