GIT Tutorial: Part 2
At a high level we will be discussing two separate instances of Git. Firstly there is the instance on your own machine which we can refer to as the local instance. Then there is the instance on some remote machine which we can refer to as the remote instance. There aren’t really any differences between the local and remote except for being on different machines. The remote instance for example could be the place where the team pushes their code to. Ultimately there usually are at least 2 Git copies, your local and somewhere that you push your copy to. Think of it like Subversion and pushing your changes to a remote repository.
Side note: quite often in documentation you will see the remote referenced as “origin” (a default name).
Creating a Git Repository
Let’s start off by creating a brand new Git Repository.
mkdir Demo cd Demo git init
This creates our Demo folder and then creates a new Git repository. Simple!
Logical sections within Git
Within an instance, Git is best visualized as 3 separate buckets.
The working directory is what you see in your folders and file system. You make code changes here.
In the Working Directory, you might create a new file called A.txt, add some content and save it.
If we run the command
This will ask Git to see what the current status is. Has anything changed? Are there any files waiting to be added to Git?
You can see in this example, Git isn’t tracking A.txt. It also tells us how to add the file.
Next you would tell Git to track this new file.
git add A.txt
Alternatively you could add all files within the directory by specifying the dot syntax.
git add .
Running Git status again we see:
The whole point of the Staging Area is to create a candidate for committing to the database. Take for example fixing a bug. It would be far cleaner and easier to read 1 commit to the database e.g. “#424 Bug fixed” rather than 10 piecemeal commits all contributing to the commit. In Git we can stage and manipulate our commits to make history more logical and easier to read.
Once you are happy with your your Staged work you would commit it to the actual repository.
git commit -m "#424 Bug fixed"
This would move our staged changes into the Repository. Essentially freezing those changes in place.
That’s it! That is a very simple example that touches upon all 3 buckets within Git.
To help visualize the bigger picture, the typical day-to-day workflow that you would use would be something like this:
- Fetch from the database (this updates your repository and brings down all information from the centralized repository)
- Pull to update your local copy with what is in the remote repository
- Make some local changes
- Add them to the Staging Area
- Commit your Staging Area to the repository
- Finally when you are happy with your commits, Push them to the remote instance
- And go to step 1 again…
Don’t worry about the other verbs that we haven’t discussed yet, we’ll touch upon them in later topics.