-
Notifications
You must be signed in to change notification settings - Fork 87
Git Repository Structure
-
seqan/seqan3- the library
- api reference (inside library code)
- cmake file and pkgconfig file
-
seqan/seqan3/wiki(wiki page ofseqan/seqan3)- "SeqAn project" organisation, e.g. who-is-who, contributor guides...
- resources for developers of the library, e.g. release check-lists
-
seqan/seqan3-manual- readthedocs stuff, but only for users of the library, not developers of the library
-
seqan/seqan3-test- unit tests
-
seqan/seqan3-util- any other stuff, e.g. additional cmake files, application templates...
Apps go wherever they want to, completely unrelated.
The idea is to add seqan3 as a submodule to the seqan3-test repo. There will also be a submodule to either google test or boost test GitHub page. But with this structure we need to establish a new Git workflow, which is going to be explained here.
Every developer has to fork the seqan3 repository and the seqan3-test repository into their own organisation. Then the seqan3-test repository has to be cloned with the --recursive flag.
cd $HOME
git clone --recursive [email protected]:my_organisation/seqan3-test.gitThis will clone and initialise all submodules included into the seqan3-test repository. There will be a master and a develop branch for both the seqan3 and the seqan3-test repository. The seqan3 repository merely contains the sources, a readme, a contributor and a license file as well as a CMakeLists.txt file for configuring the project. The entire build stuff should go into the separate repository seqan3-util.
Now let's see how we can develop a new feature. We strongly emphasise to go through the Test-Driven-Development (TDD) approach. Since we use git submodule the tests are not coupled with the sources anymore which can lead to disambiguities in the commit history, e.g. the latest commit of the test module does not reflect the proper state of the submodule.
To prepare our local working copy we first have to add the remote for our forked repository for seqan3-test and for the contained submodule.
cd seqan3-test
git remote add my_origin [email protected]:my_organisation/seqan3-test.git
git fetch my_origin
cd include/seqan3
git remote add my_origin [email protected]:my_organisation/seqan3.git
git fetch my_originIf we want to develop a new feature we create a new branch from develop in the local working copy of our seqan3-test fork.
cd ../..
git checkout -b feature/my_feature my_origin/developNow we can add a test in the proper directory. To make our test run successfully, we need to add a new feature into seqan3. So we go into seqan3 and add a new feature branch from develop.
cd include/seqan3
git checkout -b feature/my_feature my_origin/developWe give the feature branch the same name as we used for the test case. When the feature is ready and the tests pass, we can create a new pull request against the repository.