Been wondering that for a while but never really checked/asked:
why are commit messages always(?) written out as “add/change/refactor” rather than added etc. in past tense?
it would make sense to me to have it like this on a to-do list (add milk) and then say “added milk” on commit (two chars more but looks more natural to me)
So is this a convention that everyone follows or does it vary?
Why is it that after I modify a file in the working directory and save the file, git status shows the name of the modified file as “modified: filename.txt” in red, and after I do git add filename.txt and then do git status again the same message is displayed, but now in green? What does red and green really mean here?
I guess I’m a little confused about what git add actually does. I thought that I only need to add a file to the staging area once; after that git will automatically track all changes I make to a file and save the changes to the staging area. Looks like that’s not true, so then…
… What is the purpose of the staging area if it’s not automatic tracking?
How often should one push modifications to the staging area, vs. how often to commit? Should you push modifications to the staging area after every little change? At the end of a day’s work? 3-4 times a day?
The working directory - where we actually work and modify all the project files
The staging area
The git repo - the repository which holds all the ready-features we’ve developed in the working directory
I don’t really understand the staging area though. Here’s what I think it means:
When we create new files, they aren’t actually being tracked by git meaning if we modify it, we can’t see the difference (using git diff), and we can’t commit it (as it’s not being tracked). Therefore, we must add it to the staging area - so now, git is tracking it. However, once a file is being tracked, and we modify it, it will still be tracked, but will count as modified meaning only the version we previously added to the staging area is being tracked, not the one in the working directory
Hi,
I’m a little confused by what exactly diff is checking because of the lesson order. Could somebody please help. add and diff are in two different orders for our scene-1.txt file in the lesson and summary.
In the lesson, diff was ran before we add so I assumed we were just checking changes made in the working directory because we hadn’t add anything to the staging area at this stage, only edited the .txt file. After checking the diff we then add the changes.
But the lesson summary puts diff after add and says `diff’ is checking difference between staging area and working directory. So now i’m confused.
In the lesson we learnt this ‘order’: git init (creates) git diff (checks some kind of change) git add (adds to stating area. So what diff checking in previous stage before we add?) git commit
The lesson summary switched diff and add: git init git add git diff (now something has been added to check diff between staging are and working directory) git commit
There are a number of uses for git diff but without any further arguments git diff would be checking for differences between your working directory and the staging area. Check the docs if you want a little more detail-
Using git diff immediately after git init should not display any information (there aren’t even in any files in the staging area at that point). Using it after the first time running git add would also yield no information. In this case the file in the staging area matches the file in the working directory so there is no difference. If you git add and then alter the working directory file you would get useful information. For a brief explanation see below-
# start in an empty directory
touch file1.txt # create an empty text file
git init # new empty git repo
# Running git diff here is pointless
git diff # No output...
git add file1.txt # Add text file to staging area
git diff # No output again ... local file matches staging area
# If after git add you then change the file...
echo 'A change to this file' >> file1.txt
git diff # Now we get an output (file does not match staging area)
Out:
diff --git a/file1.txt b/file1.txt
index ####..#### ###
--- a/file1.txt
+++ b/file1.txt
@@ -0,0 +1 @@
+a A change to this file
# If you then stage your changes from working directory...
git add file1.txt # stage the updated file
# Running git diff now will no longer show changes
git diff # No output ...
# Working directory and staging area have the same file
For a repo that already has tracked files (e.g. for an existing repo, not from git init) changes in the working directory would show up when using git diff. It is, however, the difference between the working directory and the staging area.
With flags and arguments git diff can do a lot more but take note of how it works without arguments (staged vs. working only).
Do you need to copy the push command to the terminal every time you want to commit to GitHub or is it enough to copy it once and in the future it just automatically syncs?
It depends exactly what you mean, once you’ve set up a remote tracking repo then you wouldn’t need the address every time. For a very simple repo with one remote and one branch git push alone would then push your recent (committed) changes to the repo.
If you meant could it be set to an automatic triggered/timed commit and push then you could look into tools for doing this but that’s not really what git is for, I think you’d have an easier time with a regular cloud based backup if that’s what you wanted. Might be worth having a little look around for the differences between version control software and cloud storage.
It’s interesting that you say this as the lesson says:
Must be in quotation marks
Written in the present tense
Should be brief (50 characters or less) when using -m
and then I checked the Cheatsheet and they’re all in past tense?
Showing Git Commit Logs
In Git, the git log command shows all of the commit logs for a project. The following is displayed for each commit:
A 40-character code, called a SHA, that uniquely identifies the commit.
The commit author
The date and time of the commit
The commit message
This command is particularly useful when you need to refer back to an old version of your project. The unique SHA code allows you to identify a point in your program’s history that you would like to revert to.
This Server Side article then writes an interesting explanation into writing in the present tense.
If you want to write a git commit message properly, you should use the imperative mood. This means you need to eliminate the temptation to use gerunds or past tense in your subject lines. Don’t write a git commit subject line that talks about what you did, or what you are doing. Instead, describe what was done.
I thought Git was used to see changed before applying them, but it looks like you change the original file before doing anything. I would the the changes would be in the staging are, but we had to make changes then save them in the working space the add to staging.