× Home Tutorials Training Consulting Products Books Company Donate Contact us

NOW Hiring

Quick links


Git typical workflows. This tutorial explains typical workflows for using Git.

1. Typical Git workflows

The following description highlights typical Git workflows.

1.1. Providing a patch

Git emphasizes the creation of branches for feature development or to create bug fixes. The following description lists a typical Git workflow for fixing a bug in your source code (files) and providing a patch for it. This patch contains the changes and can be used by another person to apply the changes to his local Git repository.

This description assumes that the developer who creates the changes cannot push changes directly to the remote repository. For example you solve an issue in the source code of an open source project and want that the maintainer of the project to integrate this change into this repository.

  • Clone the repository, in case you have not done that.

  • Create a new branch for the bug fix

  • Modify the files (source code)

  • Commit changes to your branch

  • Create patch

  • Send patch to another person or attach it to a bug report, so that is can be applied to the other Git repository

You may also want to commit several times during 3. and 4. and rebase your commits afterwards.

1.2. Working with two repositories

Sometimes you want to add a second remote repository to your local Git repository and pull from and push to both repositories. The following example describes how to add another remote repository and exchange commits with both repositories.

You can add another remote repository called remote_name via the following command.

# add remote
# syntax: git remote add <remote_name> <url_of_gitrepo>
# git remote add mysecondrepo <url_of_gitrepo>

git remote -v
# see all repos

For merging the changes in mysecondrepo create a new branch called newbranch.

# create a new branch which will be used
# to merge changes coming from repository 1
git checkout -b <newbranch>

Afterwards you can pull from your new repository called mysecondrepo and push to your original repository, e.g., origin.

# reminder: your active branch is newbranch

# pull remote_name and merge
git pull mysecondrepo

# or fetch and merge in two steps
git fetch mysecondrepo
git merge mysecondrepo/newbranch

# afterwards push to first repository
# -u sets the tracking branch
# for the current branch
git push -u origin master

1.3. Using pull requests

Another very common Git workflow is the usage of pull requests. In this workflow a developer clones a repository and once he thinks he has something useful for another clone or the origin repository he sends the owner a pull request asking to merge his changes.

A pull request can be seen as a notification which includes the information from which branch and URL the changes can be pulled and also the information to which URL and branch these changes should be pulled too.

This workflow is actively promoted by the GitHub.com hosting platform but you can also provide the required information to someone via email.

You can use the git request-pull command to generate a generic pull request which you may include into an email. See Git request-pull for details.

1.4. A shared repository between developers

A very typical Git workflow is that the developers integrate their work via a shared remote repository. The following section describes a typical sworkflow for this scenario.

The shared repository is located on a server so that it can easily be reached by each developer.

The developers push to this remote repository, typically they use the remote master branch on the remote repository to integrate their work. They may also use different remote branches for shared feature development or maintenance releases.

The initial setup requires that every developer clones the remote repository or adds the remote repository as additional remote to his local repository.

1.5. Using a shared repository

To develop a change and integrate it into the shared repository, the developer would:

  • Create a new local branch for the development

  • Change content in the working tree and add and commit his changes

  • If required he switches to other branches to do other work

  • Once the development in the branch is complete he rebases (or merges) the commit history onto the relevant remote-tracking branch to allow a fast-forward merge for this development

  • Pushes his changes to the remote repository; this results in a fast-forward merge in the remote repository

Git emphasizes the creation of branches for feature development or to create bug fixes.

During this development he may fetch and merge or rebase the changes from the remote repository at any point in time. The developer may use the pull command instead of the fetch command.

Even if you have the rights to push to master in a remote repository, creating a local branch for every feature or bug fix is a good practice.

Once your development is finished you merge your changes to your master and push the changes from master to the shared remote Git repository.

2. About this website

3. Links and Literature

3.1. vogella GmbH training and consulting support


The vogella company provides comprehensive training and education services from experts in the areas of Eclipse RCP, Android, Git, Java, Gradle and Spring. We offer both public and inhouse training. Whichever course you decide to take, you are guaranteed to experience what many before you refer to as “The best IT class I have ever attended”.

The vogella company offers expert consulting services, development support and coaching. Our customers range from Fortune 100 corporations to individual developers.

Copyright © 2012-2016 vogella GmbH. Free use of the software examples is granted under the terms of the EPL License. This tutorial is published under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Germany license.

See Licence.