Git typical workflows. This tutorial explains typical workflows for using Git.
The following description highlights typical Git workflows.
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
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.
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
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
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
branch on the remote repository to integrate their work. They may
also use different remote branches for shared feature development or
The initial setup requires that every developer clones the remote repository or adds the remote repository as additional remote to his local 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
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.
|TRAINING||SERVICE & 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-2017 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.