Development Index

Git

First configure your global identity, configuration file resides on ~/.gitconfig ;

       $ git config --global user.name "User Name"
       $ git config --global user.email user@devbox
    

Assumptions of this document;

       $ git clone devbox:atom
       $ git remote -v
    

1. Team WorkFlow

This work flow is based on Vicent Driessen development model, it defines rules how branches are forked, merged and tagged. By having well defined set of branches, the project structure is used as a communication tool, allowing to work simultaneously on different stages of the development.

Main Branches;

master
Current official stable release history.
develop
Integration branch for features.

Add-on Branches;

feature (f-)
New features, improvement proposal, tests, etc...
Only fork and merge from/to develop.
release (r-)
Next release, new features not allowed.
Fork from develop, merges to master and develop.
hotfix (h-)
Hotfix only contain isolated bugfixes.
Only fork from master, merges back to master and develop.

1.1. Feature

Create a branch featurex from develop and checkout;

    $ git checkout -b featurex develop
    

Push new branch to server

    $ git push -u origin featurex
    

Rename a branch, if all feature branches start by "f-" is easy and quick to type and easy to spot;

    $ git branch -m featurex f-xpto
    

Rename remote branch;

    $ git push origin :featurex f-xpto
    $ git push origin -u f-xpto
    

Merge branch feature into develop;

    $ git checkout develop
    Switched to branch 'develop'
    $ git merge --no-ff f-xpto
    Updating ea1b82a..05e9557
    (Summary of changes)
    $ git push origin develop
    

Delete Local;

    $ git branch -D f-xpto
    

Delete Remote

    $ git push origin :f-xpto
    

1.2. Release

Software release numbers follow Tom Preston-Werner description;

    software-name-X.Y.Z.tar.xz
    
X
Major version, backwards incompatible API changes.
Y
Minor version, backwards-compatible changes.
Z
Patch version, backwards-compatible bug fixes.
    $ git checkout -b r-1.2.1 develop
    Switched to a new branch "release-1.2.1"
    $ ./bump-version.sh 1.2.1
    Files modified successfully, version bumped to 1.2.1.
    $ git commit -a -m "Bumped version number to 1.2.1"
    [release-1.2 74d9424] Bumped version number to 1.2.1
    1 files changed, 1 insertions(+), 1 deletions(-)
    

Only documentation or bugfixes are allowed in this branch. When release is ready for production merge and push to master;

    $ git checkout master
    Switched to branch 'master'
    $ git merge --no-ff r-1.2.1
    Merge made by recursive.
    

Tag new release with software-name-version, this allows meaningful ports distfiles when downloading releases from git archives;

    $ git tag -a software-name-1.2.1
    $ git push --follow-tags
    

Update branch develop with bugfixes from last release, conflict will happen in next step

    $ git checkout develop
    Switched to branch 'develop'
    $ git merge --no-ff r-1.2.1
    Merge made by recursive.
    (Summary of changes)
    $ git push
    

1.3. Tags

There are two main types of tags, lightweight and annotated. Lightweight tag is a pointer to a specific commit, much like cheap branches. Annotated tags are stored as full objects and allow to sign with gnupg, making it ideal for distributing releases.

Delete local and remote last end of life version;

    $ git tag -d software-name-0.0.12
    $ git push origin :refs/tags/software-name-0.8
    

Checkout master commit you want to start long term support and then;

    $ git tag -m "this commit is tagged" -a "software-name-1.1.8"
    $ git push --follow-tags
    

1.4. Hotfix

This branch should never exist, ;)

    $ git checkout -b h-1.2.2 master
    $ ./bump-version.sh 1.2.2
    Files modified successfully, version bumped to 1.2.2
    $ git commit -a -m "Bumped version number to 1.2.2"
    
    $ git merge --no-ff b-error-xpto
    ...
    $ git merge --no-ff b-error-xpto
    ...
    $ git commit -m "Commit severe fix"
    ...
    $ git commit -m "Commit severe fix"
    ...
    
    $ git checkout master
    Switched to branch 'master'
    $ git merge --no-ff h-1.2.2
    Merge made by recursive.
    (Summary of changes)
    $ git tag -a software-name-1.2.2
    

Conflict will happen in next step

    $ git checkout develop
    Switched to branch 'develop'
    $ git merge --no-ff h-1.2.2
    Merge made by recursive.
    (Summary of changes)
    
    $ git -D h-1.2.2
    

2. Local Workflow

2.1. Working area

Mark all deleted to commit;

    $ git ls-files --deleted -z | xargs -0 git rm
    

Mark all deleted to commit;

    $ git ls-files --deleted -z | xargs -0 git rm
    

2.2. Logs, diff commits

Create patch files to target branch/tag/ref;

    $ git format-patch --no-prefix software-v0.0.1
    

Same using diff tool;

    $ diff orig file > file.patch
    

Query last commit that affected current file path

    $ git rev-list -n 1 HEAD -- .
    $ git show f000 path/to/file
    $ git diff --name-status f000 path/to/file
    

Undo a file to specific commit

    $ git checkout f000^ -- path/to/file
    

2.3. Working with remotes

Adding a new remote;

    $ git remote add newremotename https://github.com/user/repo.git
    

Update all branches with remote;

    $ git fetch --all
    $ git pull --all
    

If you want to track all remotes run this line and then the commands mentioned above;

    $ for remote in `git branch -r`; do git branch --track ${remote#origin/} $remote; done
    

Future updates;

    $ git fetch --all
    $ git pull --all
    

Update local branches removed on remote set;

    $ git config --global fetch.prune true
    

This will prune on fetch or you can keep it manually;

    $ git remote prune origin
    
Development Index

This is part of the c9-doc Manual. Copyright (C) 2016 c9 Team. See the file Gnu Free Documentation License for copying conditions.