Git
Presenter: Hirantha Weerarathna
Road map• What is Git?• Version Control Systems• Few Useful Git Commands• Git Workflows• Git Hooks• Github
What is Git
● Distributed Version Control System● Developed by Linus Torvalds for linux kernel developments● Free Software
Version Control Systems
Distributed version control
git init-create a local repo
git clone /path-clone a repo
git add [filename]-add file into ‘staging area’
git commit -m “your_message”-commit
git status-show the status of files
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
Few Useful Commands
● Centralized workflow● Feature Branch workflow● GitFlow workflow● Forking workflow
Git Workflows
Someone initialize the central repositoryssh user@host git init --bare /path/to/repo.git
“Central repositories should always be bare repositories (they shouldn’t have a working
directory)”
Centralized workflow
Everybody clones the central repositorygit clone ssh://user@host/path/to/repo.git
Centralized workflow
John works on his featuregit add <some-files> git commit <some-files>
Centralized workflow
Marry works on her featuregit add <some-files> git commit <some-files>
Centralized workflow
John publishes his featuregit push origin master
Centralized workflow
Mary tries to publish her featuregit 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.
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”
Centralized workflow
Mary resolves a merge conflict
CONFLICT (content): Merge conflict in <some-file>
git add <some-file> git rebase –continue
git rebase --abort
Centralized workflow
Mary successfully publishes her featuregit push origin master
Centralized 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
Feature Branch workflow
Mary begins a new featuregit checkout -b marys-feature master
Building up her feature with as many commitsgit status git add <some-file> git commit
Mary finishes her featuregit push origin marys-feature
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
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.
Feature Branch workflow
Mary publishes her feature.
git checkout mastergit pullgit pull origin marys-featuregit push
Feature Branch 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.
Gitflow Workflow
Historical Branches
Mater Branch - stores the official release history
Develop Branch - serves as an integration branch for features.
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.
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.
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
Gitflow Workflow
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
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.
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
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/Bitbucketrepository.
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.
Gists
• Adds version control for code snippets, mini projects
• Each “gist” is its own Git repository
• Can be pushed and pulled using Git
References
• https://github.com• https://www.atlassian.com/git• http://git-scm.com
● 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
Staging Area
Go back
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
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