Overview
- git concepts
- handson demo
- workflow
Git Concept
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Keywords
- distributed
- version control system
- from small to very large
- speed and efficiency
from small to very large
Single developer could use git on single file project; and it's also suitable for huge project like windows
- 3.5M files 300GB
- 4,000 engineers
- 1,760 daily
- 440 branches
speed and efficiency
Git is fast, because Linus believe that speed is a feature. git is made to be fast on purpose.
Creating branch is cheap
Creating a new branch is as quick and simple as writing **41 bytes** to a file (40 characters and a newline).
So, never hesitate to create new branch.
distributed
local
git add to staging, for git commit later.
remote
- git push / pull
git could have multiple remotes, all remotes are the same. It's just convention that we use "origin" as the default remote.
when we do git push, it's actually git push <current_branch> origin
So, if we want to commit some code, we need:
- git add
- git commit
- git push
This is tedious? But it serve a purpose.
version control system
It's all about control, or in another word, source code management.
CHANGES in source code need to be managed.
Git is about managing changesets, not version.
Managing changesets has the same result as managing version, but it's conceptually different.
Taking address as example, in SG, we have
21 Lower Kent Ridge Road
But, in Japan:
東京都中央区八重洲一丁目5番3号
In Japan, there is no ROAD, only Chōme; different approach same result.
Combining changesets results in version; diff among versions gives changesets.
When using git, we should be thinking in changesets, it provides better flexibility.
For example, we have three independent features being developed, which one to be released in which version is unclear.
We could treat each feature as independent changesets, and pick the one we want to release in next version.
When source code is managed properly, we could release easily; and never have problems like:
- My code is halfly done, I must finish it before doing other changes
- We must release both feature A & B, and the code are in the same version(branch)
Demo
GUI
source tree would be the most common git GUI tool; but fork is faster.
I usually use GUI tool for change review, and command line tool for the rest.
command line tool
Install oh-my-zsh
It has default git alias and nice console.
git ignore
Each git repo should have a properly maintained .gitignore file, for example, all .pyc files MUST be ignored like they doesn't exist.
IDE files should also be ignored as it's related to individual developer's preference not the project.
House keeping
Commit and only commit the code needed.
I alway review my changes before doing git push, if my commit is not neat, I refine it with git commit --amend or git rebase -i Head~XX
Use one-line succinct comment
Never afraid to modify your commit: I use git commit --amend on daily basis.
NEVER work on master branch; only merge to master, usually:
- create new branch from master
- push branch to remote/gitlab
- review & merge to master on gitlab
-
git pullon local master
Remember to remove branch, it's easy to create branch, but if we create a lot of branch without removing them will result in messy.
work flow
Gitflow
gitflow is very popular git workflow model.
It has two main branches with infinite lifetime:
- master
- develop
and three types of supporting branch:
- Feature
- Release
- Hotfix
Personally, I don't recommend git flow, as it's a bit complicated and tedious in a release fast environment. gitlab flow is more suitable.
However, I would consider gitflow for app which has much slower release cycle.
gitlab flow
gitlab flow / github flow / bitbucket flow are similar.
Don't get puzzled their names, their main difference with git flow is that they only have one infinite lifetime branch: master
And when master changed -> production deployed.
rebase
IMHO, rebase is THE most import concept of git.
If someone state git in their CV, I always ask them to please explain git rebase to me, and 80% of time they said: I don't know / never use git rebase.
I think they don't know git. :)
by using rebase, we could keep master branch history a straight line:
Very clear to see how our code changes. And never has merge conflict. _
feature is alway based on newest master, whenever master changes, feature branch rebased. All small conflicts are resolved easily when master changes, so no more big conflict on merge.
I never run git merge XXX: it's done with gitlab merge request; but use git rebase master whenever master changes.
cherry pick
If we have there different feature branch F1/F2/F3, and now want to release F1 & F3 and one small fix from F2 with changesets C2.2, we could do:
git checkout master
git pull
git checkout -b release/r1
git merge feature/f1
git merge feature/f3
git cherry-pick C2.2
git push
git bisect
Fastest way to locate a bug
git blame
Find out commiter of each line
git filter-branch
Rewrite history completely, possible to merge two different repo into one while keeping the whole history
git submodule
suitable for light usages, but create problem if there is frequent changes, not possible to do merge, can only "overwrite".
consider merge into one single repo, or use git subrepo, but subrepo is slow.
