Working, Staging, and Repository
1. Working Area: These are the files that I (the user) am working on in my local file system (on my local computer) that I have instructed GIT to track.
I am currently working in the 'StedmanLesson14.html' file. I went ahead and made some changes to this file. GIT can always compare my 'working area' with it's local repo (repository) and know what files have changed at any time. If I were to do a 'git status' command on this file (check out my post on GIT commands), GIT will me that the 'StedmanLesson14.html' file that is located on my local directory has been modified.
See the picture below:
2. Staging Area: Once a file has been given the 'git add' command, that file is moved to the "Staging Area" (aka: The Index). These are files that have been modified and could be candidates for a 'git commit' (meaning it will be saved to my local repository-- of course, this information has not been sent to the GIT HUB repository yet). Notice the picture below where Git tells me there are files in the staging area waiting to be committed.
This is what it looks like after the 'git add' command has been issued:
3. GIT Repository Area (aka: Git Repo): The third area GIT works in is the GIT Repository Area. This is GIT's "backup" database (aka: repository). I mentioned earlier, there is a local repository for each tracked directory you have on your local computer. However, the files that were modified on your local computer (and saved on your local GIT repository) should be pushed (synched), with the GIT HUB repository, so that others in your group can see them on the GIT HUB server.
I am working with a team on the same files in the Stedman project. We are all doing our own local work on this same file, and using GIT HUB to track everyone's changes. We all have GIT installed on each of our own local computers. NOW the time has come to 'push' the changes I made on the StedmanLesson14.html to the GIT HUB Repository. That way, GIT HUB Repository will match my local GIT repository. This is the third area GIT works in. GIT HUB Repository keeps track of all the changes made to the files, who made those changes, when they were made, etc. Additionally, when someone from the team wants to work on that file, they will have the most current up do date changes. (Don't forget to check out my post on GIT commands).
See the picture below:
NOTICE IN RED: it says MODIFIED Git is suggesting to (use a "git add" with the file name) add it to the staging area |
2. Staging Area: Once a file has been given the 'git add' command, that file is moved to the "Staging Area" (aka: The Index). These are files that have been modified and could be candidates for a 'git commit' (meaning it will be saved to my local repository-- of course, this information has not been sent to the GIT HUB repository yet). Notice the picture below where Git tells me there are files in the staging area waiting to be committed.
This is what it looks like after the 'git add' command has been issued:
NOTICE IN GREEN: it still says MODIFIED but now it is in Green (above it says "changes to be committed) |
3. GIT Repository Area (aka: Git Repo): The third area GIT works in is the GIT Repository Area. This is GIT's "backup" database (aka: repository). I mentioned earlier, there is a local repository for each tracked directory you have on your local computer. However, the files that were modified on your local computer (and saved on your local GIT repository) should be pushed (synched), with the GIT HUB repository, so that others in your group can see them on the GIT HUB server.
I am working with a team on the same files in the Stedman project. We are all doing our own local work on this same file, and using GIT HUB to track everyone's changes. We all have GIT installed on each of our own local computers. NOW the time has come to 'push' the changes I made on the StedmanLesson14.html to the GIT HUB Repository. That way, GIT HUB Repository will match my local GIT repository. This is the third area GIT works in. GIT HUB Repository keeps track of all the changes made to the files, who made those changes, when they were made, etc. Additionally, when someone from the team wants to work on that file, they will have the most current up do date changes. (Don't forget to check out my post on GIT commands).
Comments
Post a Comment