The difference between centralized and distributed version control system
Getting started with GIT
Writing to repository, viewing the commit history, reverting changes
Working with remotes
Git branching
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
Nearly everything could be recovered
Easy way to share project with other
Provide the ability of effective work on one project for the whole team
You could easily find out what and when something have happened
Easy switching between different versions of project improves possible workflows
Advantages of distributed VCS
Advantages of centralized VCS
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 configuration & help
link core editor help:
GIT help & Aliases
git aliases:
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:
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