Git

Git

Introduction

This page is intended for readers to get an idea of how Git and Version Control Systems (VCS) works at a high-level. This would hopefully arm them with the ability to use it effectively. To start, let's go over some basics of VCS terminology and concepts.

Terminology

  • Repository: The database/project resources containing code, assets, and relevant files.
  • Server: The computer containing the remote copy of the repository.
  • Client: The computer containing a local copy of the repository, intended for developers to make updates locally and update the remote repository.
  • History: A running track of changes to a branch in the repository.
  • Branch: Copy of a line of modifications to code.
  • Trunk/Main/Master: The location of the primary and latest copy of the repository, this is typically in the form of a branch.
  • Commits: A set of changes with a message that builds up the history.
  • Tag: Marker in a repository's history to indicate a release.
  • Conflicts: In many cases, multiple changes to a codebase are typically merged together without conflicting results. However, in the cases where Git is unable to successfully merge in new updates to code, a conflict is created and will be required to be resolved before merging.

Actions

  • Clone: Create a local copy of a repository from the remote server.
  • Status: Check the current state of the current branch and tracked files of the repository.
  • Fetch: Downloads remote changes made to the branch.
  • Merge: Joins two histories together.
  • Pull: Shorthand for a fetch followed by a merge on the same branch.
  • Add: Add files/folders changes to be tracked.
  • Commit: Write to the history of the changes tracked and added with a message.
  • Push: Update the commit history of the remote branch using the local branch.
  • Checkout: Switch to a specific branch or commit in the history.
  • Branch: View the list of branches associated to the repository.
  • Log: View the branch history.

Updating Repositories

Now that we have some common terms laid out, we can go through a portion of the software development lifecycle. In this case, making updates to a repository. Typically, changes are placed into two primary categories, Features or Bugfixes, which can take a multitude of commits to implement. To not divert too far away from VCS and into project management, branches are commonly used to address a specific feature implementation or bugfix. It'll probably be best to leave it at that as this can greatly vary from project to project on how branches should be structured and the project management portion goes a bit out of scope of the current topic.