Skip to content

Kerem Uslular Git Research

Jump to bottom
keremuslular edited this page Feb 17, 2020 · 2 revisions

Git as a Version Control System

Why Use a Version Control System?

  • Collaboration
    With a Version Control System, everybody on the team is able to work absolutely freely - on any file at any time. The VCS will later allow you to merge all the changes into a common version. There's no question where the latest version of a file or the whole project is. It's in a common, central place: your version control system.

  • Storing Versions
    Saving a version of your project after making changes is an essential habit. But without a VCS, this becomes tedious and confusing very quickly. A version control system acknowledges that there is only one project. Therefore, there's only the one version on your disk that you're currently working on. Everything else - all the past versions and variants - are neatly packed up inside the VCS. When you need it, you can request any version at any time and you'll have a snapshot of the complete project right at hand.

  • Restoring Previous Versions
    Being able to restore older versions of a file (or even the whole project) effectively means one thing: you can't mess up! If the changes you've made lately prove to be garbage, you can simply undo them in a few clicks. Knowing this should make you a lot more relaxed when working on important bits of a project.

  • Understanding What Happened
    Every time you save a new version of your project, your VCS requires you to provide a short description of what was changed. Additionally (if it's a code / text file), you can see what exactly was changed in the file's content. This helps you understand how your project evolved between versions.

  • Backup
    A side-effect of using a distributed VCS like Git is that it can act as a backup; every team member has a full-blown version of the project on his disk - including the project's complete history. Should your beloved central server break down (and your backup drives fail), all you need for recovery is one of your teammates' local Git repository.

Git

Git is a distributed version control system where each user can make changes to an entire repository on their system. It uses command line and with git it’s easy to undo changes back and forth with a precise explanation of the changes that are made. It has the ability of:

  • Keeping a track of the changes i.e. different versions of the same file.
  • It also keeps a record of all the files present in a project.
  • Comparing and analyzing different codes with a detailed explanation.

The basic steps to start working in a Git environment is to have a local repository and a remote repository.

Local repository : A local repository is a path or a directory created by you on a local computer that is working directory. You write your code in this repository which is private to you until you push it to the remote repository.

Remote repository: Remote repository is a public directory or is a public platform to host your websites such as Github. Using Git, one could easily push a piece of code or an entire project to a remote directory.

Git Terminology:

  • Commit: stores the current contents of the index in a new commit along with a log message from the user describing the changes

  • Branch: a pointer to a commit

  • Master: the default name for the first branch

  • HEAD: a pointer to the most recent commit on the current branch

  • Merge: joining two or more commit histories

  • Workspace: the colloquial name for your local copy of a Git repository

  • Working tree: the current branch in your workspace; you see this in git status output all the time

  • Cache: a space intended to temporarily store uncommitted changes

  • Index: the cache where changes are stored before they are committed

  • Tracked and untracked files: files either in the index cache or not yet added to it

  • Stash: another cache, that acts as a stack, where changes can be stored without committing them

  • Origin: the default name for a remote repository

  • Local repository: another term for where you keep your copy of a Git repository on your workstation

  • Remote repository: a secondary copy of a Git repository where you push changes for collaboration or backup

  • Upstream repository: the colloquial term for a remote repository that you track

  • Pull request: a GitHub-specific term to let others know about changes you've pushed to a branch in a repository

  • Merge request: a GitLab-specific term to let others know about changes you've pushed to a branch in a repository

  • 'origin/master': the default setting for a remote repository and its primary branch

References:

Clone this wiki locally