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