Agenda

  1. Introduction
  2. The difference between centralized and distributed version control system

  3. Getting started with GIT

  4. Writing to repository, viewing the commit history, reverting changes

  5. Working with remotes

  6. Git branching

Getting started

Install GIT

1. WIndows https://git-scm.com/download/win

2. Linux

Fedora: run in terminal - sudo dnf install git-all

Debian or Ubuntu: run in terminal - sudo apt install git

VCS

  1. Nearly everything could be recovered

  2. Easy way to share project with other

  3. Provide the ability of effective work on one project for the whole team

  4. You could easily find out what and when something have happened 

  5. Easy switching between different versions of project improves possible workflows

Distributed vs Centralized VSC

Advantages of distributed VCS

  • Most of operations are local.
  • Repository data and history available on each local copy, so you could do a lot of operation without internet connection.
  • If central copy of data will be lost, any local copy could be used to restore central.
  • Lightweight branching.
  • Possibility of working with several remotes in one time.

Advantages of centralized VCS

  • Storing only current copy of data in a local repository could be an advantage.
  • Easier workflow for novice users.

The three states

  • Modified: you have changed the file but have not committed it to your local database
  • Staged: you have marked a modified file in its current version to go into your next commit snapshot.
  • Committed:  the data is safely stored in your local database.

This leads us to the three main sections of a GIT project:

Saves configuration for current repository

--system (Saves configuration for all system users)

--global (Saves configuration for current system user)

  • git config --global user.name “John Doe"  (To set user name)
  • git config --global user.email johndoe@example.com  (To set user email)
  • git config --global core.editor emacs (To set editor)
  • git config --global core.editor "atom --wait" (To set editor Atom)
  • git config --global core.editor "subl -n -w" (To set editor Sublime)
  • git config --list  (To get current configuration)

GIT configuration & help ​

link core editor help:

GIT help & Aliases ​

  • git help <verb>

git aliases:

  • git config --global alias.co checkout
  • git config --global alias.br branch
  • git config --global alias.ci commit
  • git config --global alias.st status  

Creating GIT repository

git init

    This command is used for putting existing project under version control. Command should be executed in the root project directory. Pay attention! After invoking this command you files will be untracked. You should track them and do initial commit manually.

git clone [url]

    This command is used to clone remote repository and create local copy for you. After cloning repository all files are in unmodified state.

    For cloning repository you could use different transfer protocols. For example: https, ssh.

Recording Changes to the Repository

Lifecycle

git status 

This command is used to find out in which states you repository files are.

GIT Initialization

GIT add

git add [file]

Put untracked file under VCS, prepare them for commit. [untracked -> staged]

GIT add

using:
git add README
git add CONTRIBUTING.md
git add .

we will get the next result:

GIT add

What will happened if we do some changes in README file?  

Git stages a file exactly as it is when you run the git add command. 

.gitignore

$ touch .gitignore

  This is a file, which you could create in the root of your repository. All files, which are match patterns from gitignore, would be untracked by default. This could be binary files; files, which are generated by IDE, logs, ect. So all of this files exist in you project directory, but you will never want to commit them to repository.

  The rules for the patterns you can put in the .gitignore file are as follows:

  • Blank lines or lines starting with # are ignored.
  • Standard glob patterns work.
  • You can start patterns with a forward slash (/) to avoid recursivity.
  • You can end patterns with a forward slash (/) to specify a directory.
  • You can negate a pattern by starting it with an exclamation point (!).

Committing changes

$ git commit // allows you to fix your staged changes.
$ git commit –a // to skip staging area

Deleting

$ git rm [file] // allows you to stage files, which should be deleted.

Moving

git mv [source][dest]

Reviewing commit history

git log

The command for reviewing commit history. By default shows SHA-1, commit name, author, email, date.

Reverting local changes

$ git commit --amend 

This command allows you to make some changes in your last commit.
$ git reset HEAD [file]

To unstaging a staged file. Git status will help you:
$ git checkout —- [file]

Unmodifying a modified file. Git status will help you again:

Working with remotes

$ git remote

To view all remote repositories.
$ git remote add [name] [url]

To add new remote repository.
$ git remote rename [old_name] [new_name]

Renaming repository.
$ git remote rm [name]

Delete repository from list.

Exchanging data with remote

$ git fetch [remote]

Allows to get copy of all remote branches
$ git pull [remote]

This command automatically does fetch and tries to do merge 
with your local branches.
$ git push [remote] [branch]

Allows to push information from your local branch to remote.

Git Branching

A branch in Git is simply a lightweight movable pointer to one of commits.

$ git branch [name] // Only creates a branch, does not switch on it.

HEAD  a special pointer, which allows GIT to know what branch you’re currently on.

$ git checkout -b [name] // Create a branch and switch.

Git Branching: Example

1

2

3

4

Branching & merging  workflow

git merge //  Join two or more development histories together

Basic merging

$ git checkout master 
$ git merge iss53 
Auto-merging README 
Merge made by the 'recursive' strategy.

Merge conflicts

$ git mergetool // run visual tool

Remote and local branches

Remote branches

git push origin --delete <branch>

Merging vs Rebasing

$ git checkout experiment 
$ git rebase master 
First, rewinding head to replay your work on top of it... 
Applying: added staged command
Need to apply forward
$ git checkout master
$ git merge experiment

Do not rebase commits that you have pushed to a public repository.

Interactive rebasing

$ git rebase -i HEAD~[count of commits] // Allows you to do interactive rebasing.

The reset magic: 3 steps

Git reflog

$ git reflog // get reference log

ad0096f HEAD@{10}: checkout: moving from new to master

d82a8e0 HEAD@{11}: commit: n3

2ae10cd HEAD@{12}: commit: n2

c1c51a3 HEAD@{13}: commit: n1

ad0096f HEAD@{14}: checkout: moving from master to new

ad0096f HEAD@{15}: commit: clean

The git time machine

Links

GIT

By Oleg Rovenskyi