Git thoughts

This brief report describes the usual work flow when using branches in Git.

Working with git involves having a so called master branch on a server which defines the truth of the current production. Instead of having each developer working directly on the main branch at all time. Each developer would normally have their own local branch which could be worked on independently of the main branch. Each change on this developer branch is only stored locally unless specifically pushed to the master branch. Each developer isn't confined to just one branch, They can at anytime in git have any number of branches, each being able to be pushed/merged individually from each other. In git you have the option to create your own named branches at will. This makes it easy to code and test out a new feature that might not be used in the main branch by simply making a new branch with a name like "dev-A-test-feature".

Git offers two main branching options. Cloning, which is pretty self explanatory, and named branches. Named branches enables a clear and concise dividing of the current project. An example of named branching can be seen utilized below. Here we see two developers working on a project where developer B has his own branch where he is working on a test feature. He can simultaneously work on the master branch and the test feature independently. Then on a laster date decide Wether or not to include or scrap the feature branch.

  Dev-A
  O--o
 /    \
/      \
Master  \
O--------O------O---------------O--?
 \             /               /  /
  \           /               /  /
   O---o--o--o --o--o----o---o  ?
   Dev-B             \         /
                      \       /
                       O--o--o
                       Dev-B-test-Feature

there are a couple of good work practices which should be utilized regardless of the used revision control system. Even though they aren't specific to Git they are worth having written down. A good work practice when working on any branch is to keep commits short and focused. Don't have a several hundred lines commit with a message like "fixed spelling errors, bug and added new feature". This will make it very hard to later undo the commit properly if it turns out to be faulty. Keep commits short and commit messages descriptive and with relevant information. Another good practice advice is to pull and merge often with the master branch in an attempt to minimize conflicts which can be tedious to resolve.