Introduction To Git Concepts – Overview
Are you using Git for the first time and feeling the challenge of the initial Git concepts? I have mentored many people learning Git and discovered a few core concepts most important to first understand. After discussing these concepts, most new Git users can successfully perform daily work with Git. This post summarizes these core concepts to help initial learning and understanding of Git. Once understanding Git’s basic operations, Git’s branch management, alternate commit approaches, and multiple remote repos are within reach.
Conceptual Diagram
This conceptual diagram shows the basic actions/commands and the movement of the files/content with Git. Refer to this diagram with the below sections.
Concept 1: Repositories
Git has two repository types: remote and local. The remote repo is typically located on a different machine and is for your indirect use to share the files. The local repo is on your computer and for your direct use. Note that Git supports multiple remote repositories.
Remote Repo
Typically, we work in teams and need to work on a codebase together. The codebase is on a “central” server and people retrieve files from it and commit to it. Git refers to the centralized server as a “remote repository”. The remote repo is usually not on your machine and is the one shared by the team. The team “pushes” commits to it when ready to share them with the team. While one of your remote repos could be another team member’s local repo, one is typically a Git repo on a server declared as the central/official repo.
Note that a remote repo is optional – when not sharing code with others, there is technically no need for a remote repo (you may want one for backup or Continuous Integration though, which is a remote repo). There is also no need for a remote repo if your local repo is considered the central one by all team members (which means your local repo is their remote repo).
GitHub, GitLab, and BitBucket are examples of hosted Git services and are also remote repos.
Local Repo
The local repo is on your computer (resides in the .git directory) and has all the files and their commit history, enabling full diffs, history review, and committing when offline. This is one of the key features of a “distributed” version control system (DVCS), locally having the full repository history.
Creating a Local Repo from a Remote Repo
Use the Git clone command to create a local repo with all of the remote repo’s history. Only use this command once – when initially obtaining the files and creating the local repo from a remote. Git is very conservative about overwriting files – with the clone command, Git will stop with an error message when the directory you specify to create the local repo in is not empty.
Git Clone Example
$ git clone http://username@hostname.com/giturl/gitreponame.gitConcept 2: Committing is a Multi-Step Process
Git has a three step process to share your files with the team: add, commit, and push.
- Add copies new or updated files to the “stage” or “index” (documentation and other references use both terms).
- Commit copies the staged files to the local repo.
- Push copies the committed files from the local repo to the remote repo.
1. Add/Stage (Index) Files to Commit
Git commits files from the “staged files” list, also referred to as “indexed files”. Contrary to most other SCMs, Git requires staging all files before committing, not just new files but modified files as well.
To put files into the Git stage area, use either the stage or add command (stage is a synonym for the add command). The add command is more commonly used than the stage command. New Git users tend to misunderstand the Git add command as they relate it to other SCM add commands, such as Subversion and Perforce, which use add solely to place new files under source control.
Note: while the stage command is available from the command line, most Git GUI programs use the word Add for the action, not stage. Even an error message for the stage command mentions add:
$ git stage
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?Git Add Examples
$ git add filename.txt
$ git add .2. Commit
Git commits all staged files together as an atomic commit to the local repo. This step is very similar to other SCMs and includes a commit message.
Git Commit Example
$ git commit -m "This is a basic commit message."3. Push
Use the push command to share the local repository commits to the remote repository. This step is only present in distributed version control systems such as Git. Without any arguments, push uses the configured remote repo for the current branch.
Git Push Example
$ git pushConcept 3: File Diffs in Workspace, Stage, and Repo
Files can exist in three local locations with Git: committed, staged, and workspace. The same file can have different content in each location:
- Committed in the repo is the HEAD version, the contents as the file was last committed.
- Staged in the index has edits made or the file removed, added to the index, ready to commit.
- Workspace is the working area with changed and unchanged files representing work in progress (usually most files are unchanged, having the same content as the committed version).
Locations 2 and 3 are “changes in-progress” and not yet shareable with others.
A very important concept with this is Git does not auto-update a staged file with additional edits. When making additional edits to a file after staging it, the staged file does not contain the additional edits and they only reside in the workspace. You must once again “git add” the file for the staged one to have them. This feature becomes useful in multiple ways, particularly with Git’s feature to stage only some of a file’s changes in prep for commit.
While it is more of an advanced Git concept, Git actually tracks file content, not whole files. It recognizes the same content in multiple files and easily tracks content movement from one file to another.
Refer to multiple options to the add command for useful features, such as -i, -p, and -u
The Git diff command options allow comparing between the three locations (and more).
- Specifying no option compares the workspace to the staged/index version.
- Specifying –cached or –staged compares the staged/index version with a committed version.
- Additional diff option include comparing with any two files on disk, comparing two comments, and any file with any commit.
Git Diff Examples
# compare unstaged changes with staged and committed
$ git diff
# compare non-pushed changes (unstaged, staged, committed) with committed/HEAD
# as of last fetch, so possibly want to fetch first
$ git diff origin/master
Besides experimenting with the diff command, refer to the diff command help for more info. https://git-scm.com/docs/git-diff
Command Summary – Conclusion
For beginning use of Git, this section summarizes some basic commands.
Obtaining Files from a Remote Repo
Clone
The clone command creates a new local repo from the remote repo. Use this command only once to initially pull the files and history from the remote repo.
Fetch
The fetch command retrieves updated files from the remote repo that are not yet in your local repo.
Merge
The merge command merges the contents from the local repo into the workspace. After understanding “merge”, learn about “rebase” and prefer it instead of merge when applicable.
Pull
The pull command is simply a fetch followed by a merge (or rebase, if configured so).
Committing Files
Add / Stage
The add or stage command adds the file in its current state to the Git stage area (this includes a deleted file).
Commit
The commit command commits the staged files to the local repo.
Sharing Files to a Remote Repo
Push
The push command updates a remote repo by copying the file updates from the local repo to the remote repo. Note that this is done on a per branch basis.
NOTE: An advanced usage is push/pull with another person’s repo.
Git sees it as just another remote repo. However, this feature allows collaboration before committing (via pushing) to the official remote/central repo.
About Intertech
Founded in 1991, Intertech delivers software development consulting to Fortune 500, Government, and Leading Technology institutions, along with real-world based corporate education services. Whether you are a company looking to partner with a team of technology leaders who provide solutions, mentor staff and add true business value, or a developer interested in working for a company that invests in its employees, we’d like to meet you. Learn more about us.
