Project

General

Profile

Git

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.
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows

Type of workflows

1. Historical branches

This workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number, recommended for small projects and one developer.

2. Feature branches

Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master. Recommended for medium/big projects with more than one developer/collaborators.

3. 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 (or the current release branch), and master should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with master.

Common commands

Clone a project:

git clone http://jro-dev.igp.gob.pe/rhodecode/<repo> <repo_name>

Create a new branch (new_feature) and switch to the new created branch

git branch <new_feature>
git checkout <new_feature>

Commit all your changes

git commit -am "This is a new feature"

Update your local repository with server

git pull

Upload your changes to the server

git push

Add new remote to your local repository

git remote add http://jro-dev.igp.gob.pe/rhodecode/<fork_repo> <fork>
git fetch <fork>

Merge branch "new_feature" with branch "develop"

git checkout develop
git merge new_feature or git merge fork/new_feature if new_feature is in remote fork

Tag a version e.g. v1.2 for realease

git checkout master
git tag v1.2

Pull requests (Rhodecode)

All merges with develop and master branches of the main repository must be done using pull requests, as follows:

  1. Clone/Fork the main repository
  2. Create a new branch issue3 off of the develop branch.
  3. Make your changes and commit them.

If branching of the main repository

  1. Push your branch to the main repository
  2. Create a Pull Request to merge issue3 branch with develop branch and assign a reviewer

If forking the main repository

  1. Add the main repository as new remote.
  2. Update your branch issue3 with the main repository develop
  3. Push your branch to your fork repository
  4. Create a Pull Request to merge issue3 branch from fork with develop branch from the main repository and assign a reviewer

Recommended best practices

  • Commit often and related changes e.g. fixing two different bugs should produce two separate commits.
  • Test Before you commit.
  • Write good commit messages.
  • Choose a workflow for your development.
  • Do not work directly in the master branch

Referencia: https://www.atlassian.com/git/tutorials/comparing-workflows

feature_branch.png View (39.8 KB) Juan Carlos Espinoza, 08/16/2017 07:46 PM

bug_branch.png View (46.4 KB) Juan Carlos Espinoza, 08/16/2017 07:46 PM

developer_branch.png View (20.9 KB) Juan Carlos Espinoza, 08/16/2017 07:46 PM