Git is a distributed version control system developed by Linus Torvalds for Linux kernel development. The presentation discusses various Git concepts and workflows including commands like git init, git clone, git add, git commit, and git push. It covers workflows like centralized, feature branch, and Gitflow along with hooks and GitHub features like pull requests and gists.

1. Git
Presenter: Hirantha Weerarathna

2. Road map
• What is Git?
• Version Control Systems
• Few Useful Git Commands
• Git Workflows
• Git Hooks
• Github

3. What is Git
● Distributed Version Control System
● Developed by Linus Torvalds for linux kernel developments
● Free Software

4. Version Control Systems
Distributed version control

5. git init
-create a local repo
git clone /path
-clone a repo
Few Useful Commands
git add [filename]
-add file into ‘staging area’
git commit -m “your_message”
-commit
git status
-show the status of files

6. Few Useful Commands
git remote add –u [remote_repo_name] [remote_repo_url]
git push [remote_repo_name] [branch_name]
-push into remote repo
git pull [remote_repo_name] [branch_name]
-pull from remote repo
git branch [branch_name]
-create a branch called ‘branch_name’
git checkout [branch_name]
-checkout a branch
git merge [branch_name]
-merge a branch

7. Git Workflows
● Centralized workflow
● Feature Branch workflow
● GitFlow workflow
● Forking workflow

8. Centralized workflow
Someone initialize the central repository
ssh user@host git init --bare /path/to/repo.git
“Central repositories should always be bare repositories (they shouldn’t have a working
directory)”

9. Centralized workflow
Everybody clones the central repository
git clone ssh://user@host/path/to/repo.git

10. Centralized workflow
John works on his feature
git add <some-files>
git commit <some-files>

11. Centralized workflow
Marry works on her feature
git add <some-files>
git commit <some-files>

12. Centralized workflow
John publishes his feature
git push origin master

13. Centralized workflow
Mary tries to publish her feature
git push origin master
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

14. Centralized workflow
Mary rebases on top of John’s commit(s)
git pull --rebase origin master
“--rebase option tells Git to move all of Mary’s commits to the tip of the master branch after
synchronising it with the changes from the central repository”

15. Mary resolves a merge conflict
CONFLICT (content): Merge conflict in <some-file>
git add <some-file>
git rebase –continue
git rebase --abort
Centralized workflow

16. Centralized workflow
Mary successfully publishes her feature
git push origin master

17. Feature Branch workflow
•Feature Branch Workflow still uses a central repository
•All feature development should take place in a dedicated branch
instead of the master branch.
•makes it possible to leverage pull requests

18. Feature Branch workflow
Mary begins a new feature
git checkout -b marys-feature master
Building up her feature with as many commits
git status
git add <some-file>
git commit
Mary finishes her feature
git push origin marys-feature

19. Feature Branch workflow
She files the pull request in her Git GUI asking to merge marys-feature into
master
Bill receives the pull request
Bill takes a look at marys-feature.
He decides he wants to make a few changes before integrating it into the official
project

20. Feature Branch workflow
He and Mary have some back-and-forth via the pull request.
Mary edits, stages, commits, and pushes updates to the central repository.
All her activity shows up in the pull request, and Bill can still make comments
along the way.

21. Feature Branch workflow
Mary publishes her feature.
git checkout master
git pull
git pull origin marys-feature
git push

22. Gitflow Workflow
•Gitflow Workflow defines a strict branching model designed around the
project release.
•Provides a robust framework for managing larger projects.
•Doesn’t add any new concepts or commands beyond what’s required for the
Feature Branch Workflow.
•In addition to feature branches, it uses individual branches for preparing,
maintaining, and recording releases.
•The Gitflow Workflow still uses a central repository as the communication hub
for all developers.

23. Gitflow Workflow
Historical Branches
Mater Branch - stores the official release history
Develop Branch - serves as an integration branch for features.

24. Gitflow Workflow
Feature Branches
•Each new feature should reside in its own branch
•Feature branches use develop as their parent branch not the master.
•When a feature is complete, it gets merged back into develop.
•Features should never interact directly with master.

25. Gitflow Workflow
Release Branches
•Once develop has acquired enough features for a release, you fork a release branch off of
develop.
•Only bug fixes, documentation generation, and other release-oriented tasks should go in
this branch.
•Once it's ready to ship, the release gets merged into master and tagged with a version
number.
•Then should be merged back into develop.

26. Gitflow Workflow
Maintenance Branches
•Maintenance or “hotfix” branches are used to quickly patch production releases.
•This is the only branch that should fork directly off of master.
•As soon as the fix is complete, it should be merged into both master and develop

27. Git Hooks
•Git has a way to fire off custom scripts when certain important actions occur.
•There are two groups of these hooks:
client-side: triggered by operations such as committing and merging
server-side: run on network operations such as receiving pushed commits.
•Hooks are local. Not copied in a clone operation
•The built-in scripts are mostly shell and PERL scripts, but you can use any
scripting language

28. Git Branching and Merging
• SVN branches are only used to capture the occasional large-scale
development effort
• Git branches are an integral part of your everyday workflow.
• Git branches is much more lightweight than SVN’s model
• Every bug fix or feature should start in a new branch despite the size of the
work
• SVN branch house a copy of the trunk but it doesn't store any information
regarding when and what things got merged back in.

29. Github
GitHub provides a web-based graphical interface, desktop as well as mobile
integration and several collaboration features such as wikis, task management,
and bug tracking and pull requests

30. How Pull Request Works
1. A developer creates the feature in a dedicated branch in their local
repo.
2. The developer pushes the branch to a public Github/Bitbucket
repository.
3. The developer files a pull request via Github.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature into the official
repository and closes the pull request.

31. Gists
• Adds version control for code snippets, mini projects
• Each “gist” is its own Git repository
• Can be pushed and pulled using Git

32. References
• https://github.com
• https://www.atlassian.com/git
• http://git-scm.com

34. Staging Area
● aka. index
● holding area
● allow you to split a large commit
● You can also commit specific lines of files if you really wanted
● use ‘git gui’
● used for temporarily stashing your changes
Go back

35. Rebase
•Put your commit after all others
•Transferring each local commit to the updated master branch one at a time.
This means that you catch merge conflicts on a commit-by-commit
•should not do if someone else clone/fork from your repo
Go back

36. Pull Request
•Pull requests are a mechanism for a developer to notify team members that
they have completed a feature.
•Give other developers the opportunity to sign off on a feature before it gets
integrated into the official project
•If you get stuck in the middle of a feature, you can open a pull request asking
for suggestions from your colleagues.
Go back