Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Here below are some good practices for using the Git Version Control system.
For Individual Repositories
1. When working on bug fixes
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 person who creates the changes cannot push changes directly to the remote repository. For example you may solve an issue in the source code of an Open Source project and want that the maintainer of the Open Source project integrates this into his project.
- 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.
2. Using Git pulls
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.
Working with multiple repositories
3. When working with multiple 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
Shared Repositories
1. Shared repository between developer
A very typical Git workflow is that the developer integrate their work via a shared remote repository. The following section describes a typical Git workflow for this scenario.
The shared repository is located on a server so that is 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.
2. Workflow
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.
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.
3. Using branches
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.
Leave a Reply