Agenda
- Introduction
-
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
Getting started
- Create repo on https://github.com/ or https://bitbucket.org
- Install git bash https://git-scm.com/downloads
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
-
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
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
- https://github.com/
- https://git-scm.com/downloads
- https://git-scm.com/book/ru/v2
- https://gist.github.com/octocat/9257657
- https://help.github.com/articles/associating-text-editors-with-git/
- http://blog.atom.io/2014/03/13/git-integration.html
- https://habrahabr.ru/post/157175/
- https://developer.atlassian.com/blog/2015/12/tips-tools-to-solve-git-conflicts/
GIT
By Oleg Rovenskyi
GIT
- 1,221