The present document aims at describing how a developer should contribute to CTK.

!–

  1. Prerequisites
    • Create an account on github.com
    • Fork http://github.com/commontk/CTK
    • Introduce yourself $ git config –global user.name “Your Name” $ git config –global user.email “you@yourdomain.com”
    • Use correct line endings (more info) [On Linux] $ git config –global core.autocrlf input [On Windows] $ git config –global core.autocrlf true

  2. Checkout your fork cd MyProject git clone git@github.com:MYACCOUNT/CTK.git cd CTK git remote add origin git@github.com:MYACCOUNT/CTK.git git remote add upstream git@github.com:commontk/CTK.git

  3. Publishing your branch
  1. Checkout a branch from a different fork
    • You may want to collaborate with an other developer and work conjointly on a feature.
    • Let’s say, jcfr published the branch awesome_feature on his fork. You should do the following to check out his branch: git remote add jcfr git://github.com/jcfr/CTK.git git fetch jcfr git checkout -b awesome_feature refs/remotes/jcfr/awesome_feature or git checkout -b awesome_feature jcfr/awesome_feature
    • You should now have a local branch named awesome_feature. You can now add, commit and publish your work.
  2. Sync your topic branch
    • If a collaborator previously checked out your published branch, committed some changes, then published a revised branch on his github fork, you may want to grab its changes.
    • Different ways: 1) If you didn’t work on your branch, you could do the following: git fetch jcfr git checkout my_topic git merge jcfr/my_topic

2) If you worked on your branch while your collaborator was working, you may want to select only the commit your collaborator pushed on his fork:

git fetch jcfr git checkout my_topic git cherry-pick sha1 # sha1 identifying a specific commit

  1. Integrate your new feature After it has been validated and tested, your changes could be integrated to master following two approaches:

git fetch upstream # Retrieve change from upstream repository git checkout master # Checkout your local “master” branch git reset –hard upstream/master # Make sure your local branch is up-to-date. git merge new_feature –log –no-ff # Merge locally to “master” - Your changes are now integrated git push upstream # Publish your change on the official repository git push origin # Publish your change on your fork

!–

!–

  1. Tutorial The idea behind the tutorial is the following, it will guide you through the basic step allowing to:
    • Step1 - Fork and clone the tutorial repository
    • Step2 - Create a new feature from master branch
    • Step3 - Add and commit a file representing the feature
    • Step4 - Merge the feature into the next branch
    • Step5 - Refine your feature by doing an additional commit
    • Step6 - Merge again with ‘next
    • Step7 - Merge feature with master

The ‘tutorial feature’ you will create could be correspond to a TXT file containing either a proverb, sentence, thought of the day, proverb, …

For example:

You will find a repository named GitTutorial here: http://github.com/commontk/GitTutorial

  1. Git Commit Style
    • Write very descriptive and concise first line summary of your commit ** try to stick to 50 characters max (no more than 65) ** do not use ‘COMP’ ‘ENH’ etc. (these cut into your 50 characters) ** summary should be a complete English sentence starting with a capital letter (terminating period is optional). Ideally the sentence should be using present tense (“Add” vs “Added”, “Fix” vs “Made fixes”…)
    • Include a blank line after the summary and then a more detailed multi-line description (72 character max line length)
    • In the body of the commit message, include #123 where 123 is the issue number. If a final commit fixes the issue, include “Fixes #123” or “Closes #123” in the commit message.
    • Use codegit merge –log –no-ff topicname/code (this keeps the logs messages of the merged branch)
  2. CTK Coding Style The overall policy is to follow the coding conventions of the parent classes unless there is an accepted CTK exception to improve consistency or usability (to account for inconsistency in the parent class system).

//—————————————————————————- void Foo::setName(const QString newName) { Q_D(Foo); d-Name = newName; }

//—————————————————————————- QString Foo::name() const { Q_D(const Foo); return d-Name; } … /syntaxhighlight

//—————————————————————————- bool Foo::doSomething(int count) { // Better for(int i=1; i count; ++i) { if (i == 100) { qDebug() “i = 100”; break; } }

// Poor for(int i=1; i count; ++i) if (i == 100) { qDebug() “i = 100”; break; } }

/syntaxhighlight

  1. FAQ
    • What the meaning of fatal: The current branch master is not tracking anything. ?