Skip to content

Git

Prereq

Command Line

Terminology

  • VCS - Software designed to record changes made to file(s) over time. Allows ability to revert and compare file(s) back to dif version.
  • Git - tool that tracks changes to source code just like any other Version Control Systems.
  • Project - your code project that holds files with source code, config files, etc.
  • Repository - Storage area for git that gets created when you do git init and stores snapshots of project
  • Indexing - Adding a file to the staging area
  • Commit - A snapshot of the project
  • Merging -
  • Master branch -
  • Conflict - Changes to the same lines in the same files when merging from different branches
  • Remotes - A link from the local repository to the shared repository
  • Github/Gitlab/Bitbucket - Git based online service that can host code repositories, provide issue tracking, workflow, etc
  • Fork - Remote clone of a remote repository
  • Pull Request - Telling the original repo that a fork has changes that should be pulled from fork into original project
  • Tracked files - are files that have been added to the commit snapshot as those that git tracks
  • Untracked files - any files added to project since last snapshot that git hasn't started tracking yet.

Version Control System Advantages

  • Detailed History - Version control gives a detailed history of project such as changes, messages, dates, etc
    • Useful for code or anything else. Similar to saving multiple version of same file
    • It's not useful as a backup if the whole repo is on one disk
  • Manage Multiple Versions of a project at the same time
    • Using Branching and git checkout to switch between branches. git merge master to pull in any common changes fixes
    • Eg: Have different version of an app that sometimes stay same but one has more features
  • Sharing Code between developers and/or teams
    • Using Branching and merging
    • Eg: Developer A and Developer B create their own feature branches and merge back to master
      • To avoid huge conflicts at merging, practice should be to merge back into main branch often
  • Coordinating Teamwork
    • Can use Issue trackers or Bug trackers and integrate with source code
    • Can use CI/CD servers that connect to repo

Git Vs Subversion

Client-Server Version Control (Eg. Subversion)

  • The repository is on the server somewhere remotely and all developers connect to it
    • Each developer has a copy of the repository files.
    • To view history, etc, developer needs an active connection to the server
  • Once the files are changed, before committing, need to get latest changes from server, fix conflict and then send the entire thing to server

Distributed Version Control (Eg. Git)

  • The repository is some cloned with a hidden directory (ls -a) called .git
    • Entire history is in that cloned directory
  • Developer can commit, create branches, etc locally.
  • The local copy is connected to the remote repository through remotes.
  • Allows complicated workflows such as open source workflow (fork, clone, commit, push to fork, pull request to original)

When to not use git

  • Git isn't good for trying to version control large binary files, etc pictures, videos
  • Initially less user friendly and needs some training compared to subversion

Git usual situations

Create repo from existing folder and push to Cloud

  • You have a project with a bunch of files (code, config, etc)
  • You created an empty repository in either Github or Gitlab
  • git init
    • To start versioning and keeping snapshots of the project, can navigate to the interested folder and run this command to make a repository
  • git add .
    • will add all files in the current repo as files that will go with the next commit(called indexed)
  • git commit -m "Init commit/Commit message"
    • will take a snapshot of the project and put it in repository
  • git remote add origin <https://githubOrGitlaborWhatever.com/username/reponame.git>
    • Links the local repository to the remote repository that allows us to push and pull changes between the two
  • git push -u origin master
    • will be prompted to enter github/lab username and password

Push existing repository to cloud

  • You have a project that's already an existing git repo
    • To check, do git log
      • If it says something like "fatal: not a git repository..", then this is not an existing repo
  • git remote add origin <https://githubOrGitlaborWhatever.com/username/reponame.git>
  • git push -u origin master

Git stages and states

Stages a file can be in

  • Staged to Committed
    • Changed committed to be part of the commit snapshot
  • Committed to Modified
    • File changed from what's been committed previously
  • Modified to Staged
    • Files marked to for next commit

States of a git project

  • .git directory (repository)
    • files in this state are committed and recorded as commits (snapshots)
    • 'origin' of project data and what's pulled down from remote repos
    • git stores the metadata for the project ( in .git folder)
  • Working Directory
    • A copy (checkout) of one version of the project from origin
    • Any changes made here can be added to the staging area
  • Staging Area (aka Index)
    • Files in this state were modified and added to be staged for the next commit
    • Sites between working directory and repository
    • can use this area to stage items from working directory that can go in next commit

Git installation

Git Commands (all start with git)

  • All commands need to start with git
    • eg: git tree
  • --version
    • Get git version
  • config
    • Set git config so git can identify who made the changes
      • git config --global user.name "Fake Human"
      • git config --global user.email "fakehuman@gmail.com"
      • The same commands without the --global override the config for specific project if run in specific project
    • config --list
      • Lists all settings git has
    • config <config.key>
      • Eg git config user.name
      • Shows value of a single setting
  • man git
    • Get full git manual that you can scroll forever
    • porcelain commands are the high level commands used day to do
    • plumbing commands are for low level usage. Don't use if you don't know what you're doing
  • help <sectionname>
    • Eg: git help config
    • Takes you to the section you're interested in the git manual
    • git help
      • gives a succinct list of commands you'll use most of the time (shorter list of porcelain commands)
  • tree
    • shows entire files and directories tree
  • init
    • puts project under git
    • responds with Initialized empty Git repository in blah and adds git configuration to hidden .git subdirectory
    • adds all files in the folder that this was run in to be version controlled by git
  • add .
    • tells git which files need to be indexed so they're ready to go for the next commit. In this case, all files in the current directory (.)
  • commit -m "some message you want to write to remember what the snapshot is for"
    • creates a snapshot of all files that have been indexed
  • log
    • give a list of all the commits and the commit details
  • status
    • gives current status of the project such as which files have been modified since last commit
  • clone <serverNameThtEndsInGit>
    • copies the entire repository including commits, history, etc
  • remote
    • git remote add <remoteName> <https://blah.git>
      • Eg: git remote add origin https://gitlab/human/dummyproject.git
      • Links the local repository to the remote repository that allows us to push and pull changes between the two
  • diff e5f9a833 c9fc877089
    • Gives info (file and changed lines) on what changed between two commits/snaphots
    • Needs full or partial hexadecimal commit ids (can use git log to get the ids )
  • checkout e5f9a833
    • can time travel and get content of a previous or future commit and put it in our file system to test, etc
    • aka git switch
  • branch newBranchName
    • creates a branch with the commits from the branch you were just in
  • pull
    • get changes from remote repository to local repository
  • push
    • push changes from local repository to remote repository
    • Eg git push origin master - push changes to master branch on the remote repository labelled 'origin'
  • merge branchName
    • used to merge changes from branchName to the branch you're in
      • should go to the branch you want to merge changes into and then replace branchname with any branch changes you want to bring in.
    • Eg. git merge master into a feature branch
Last update: August 26, 2020