Project GIT of IVD and MD

.gitignore

@@ -0,0 +1,2 @@
+sunset.JPG
+beach.JPG

AUTHORS.md

@@ -0,0 +1,8 @@
+# authors who contributed to this project
+
+Martain Dagnelie
+Ilse Van Dromme
+
+# Author who initialized the project
+
+Bruna piereck

Examples/Ex_folderstructure_1.md

@@ -0,0 +1,10 @@
+mijn-project/
+│
+├── README.md              # Projectuitleg
+├── LICENSE                # Licentie-informatie
+├── .gitignore             # Bestanden om uit Git te houden
+├── docs/                  # Documentatie
+├── examples/              # Voorbeeldcode of toepassingen
+├── src/                   # Broncode (source)
+├── tests/                 # Unit tests
+└── .git/                  # Verborgen map die Git zelf beheert

Examples/Ex_folderstructure_2.md

@@ -0,0 +1,22 @@
+mijn-python-project/
+│
+├── README.md
+├── LICENSE
+├── requirements.txt       # Python dependencies
+├── .gitignore
+│
+├── src/
+│   └── mijnmodule/
+│       ├── __init__.py
+│       ├── calculator.py
+│       └── utils.py
+│
+├── tests/
+│   ├── test_calculator.py
+│   └── test_utils.py
+│
+├── examples/
+│   └── basic_usage.py
+│
+└── docs/
+    └── collaboration_strategy.md

Examples/Ex_folderstructure_3.md

@@ -0,0 +1,23 @@
+mijn-webproject/
+│
+├── README.md
+├── LICENSE
+├── package.json           # NPM configuratie
+├── .gitignore
+│
+├── public/                # HTML, favicon, etc.
+│   └── index.html
+│
+├── src/                   # JS code
+│   ├── app.js
+│   └── components/
+│       └── Button.js
+│
+├── styles/                # CSS of SCSS
+│   └── main.css
+│
+├── examples/
+│   └── example.html
+│
+└── docs/
+    └── collaboration_strategy.md

LICENSE

@@ -0,0 +1,5 @@
+MIT License
+
+Copyright (c) 2025 [ILSE VAN DROMME]
+
+Permission is hereby granted, free of charge, to any person obtaining a copy...

README.md

@@ -47,3 +47,14 @@ Once with the final version you must <span style="color:mediumBlue">make a pull
 -------------------------------------------------------------------------------------------------
 
 This project is part the first evaluation of the micro-credetial that is offered by [VIB](https://vib.be/en#/) and [UGent](https://www.ugent.be/en) with the aim to improve data analysis reproducbility in science. A micro-credential is like a mini-diploma that you have followed a course and learnd a new skill that is valuable for your carrear. If you are interested to register you can find more detais in the [UGent registration page](https://studiekiezer.ugent.be/2025/micro-credential-reproducible-data-analysis-an-essential-capability-in-modern-science-en).
+
+
+# finalization of this project
+In the develop_ilse branch all documentation can be found in the doc folder. 
+i.e. a cheatcheet for the git commands and a documentation file which describes the git concepts.
+Note that 2 conflicts occured: 1 by MD who solved the issue regarding the .gitignore file and 1 conflict when merging IVD branch with the main. Due to this last conflict 2 cheetcheat documents are defined and 2 documentation documents (documents and dictionary) 
+additionally there is a ref folder with a references file
+a res folder with some pictures
+a src folder with some basic code
+and an authors file.
+

doc/cheetcheat_IVD.md

@@ -0,0 +1,82 @@
+<<<<<<< HEAD
+# Basic Commands
+
+`git add`  <file>
+The changes in this file go from your local folder to the staged area, which is one step before committing the changes to your local remote repository
+
+`git commit -m "message"`
+with this command the changes go from the staged area to the local repository (note: the local repository is captured in .git file in the folder)
+`git commit`
+you will get a message that no commit can be done if you don't specify a message, therefore an editor will open to add a message to the commit
+
+`git status`
+this gives you the status of your changes, which ones are not yet committed, which ones are not yet added or are completely new files 
+
+`git log`
+this gives you the history of your timeline
+options: --help, --abbrev (smaller ids), -n number (limits the. number of commits to go back)
+press q for quit, to go back to your terminal
+
+`git diff commit1 commit2`
+gives you a comparison between the 2 commits, note oldest file first and newest file after
+
+`git show commit1 commit2`
+shows you both commits so that you can see more information but the changes are separately presented and not line by line
+
+`git remote add origin` <address>
+create the bridge between local repository and github repository, copy the adress from your github page after you created a new repository, the name of the bridge is origin
+
+`git push`
+to get your timeline and changes to the repository of github
+
+`git push --set-upstream origin main`
+to set the push for the first time
+
+`git pull` 
+to get the lastest update from github
+
+`git revert`
+get to your previous git if you don`t want the last commit
+e.g if you made a mistake, but commited that mistake, you can git revert, and then go back to the previous version, if you then still want to go back further then you can revert once more, note that it does keep the history of the revert commits, every revert is a new commit
+
+`git reset`
+erasing all your commits, note: this mostly not prefered as this erases your history
+
+`git clone`
+it will recover the full project in case you lost the folder locally
+or when you start locally from scratch 
+
+`git branch` <new branch>
+to create a separate branch
+
+`git branch -a`
+list branches that exists, with the -a option you will see which branches are in the remote area
+
+`git checkout`
+to checkout the branch you would like to adjust
+
+`git checkout -b <new name>`
+this is to create a new branch and checkout immediately in one step
+
+`git tag`
+tags the current commit
+
+`git tag <name> <commitID>`
+tag a previous commit
+
+`git merge` <branchname>
+to merge this branch to the checkout branch
+
+`git clean` -f
+to remove untracked files like rds files or temporarily files
+
+`git stash`
+Temporarily saves changes that are not ready to commit, allowing you to switch branches without committing.
+
+`git cherry-pick` <commit>
+Given one or more existing commits, apply the change each one introduces, recording a new commit for each. 
+Apply a single commit from one branch onto another.
+useful when you only want to take a specific change without merging the entire branch.
+
+`git blame`
+hows who last modified each line in a file — great for debugging or tracking code changes.

doc/cheetcheat_MD.md

@@ -0,0 +1,60 @@
+# this file will be our cheetcheat for the commands
+## starting a repository
+`git init`: start a new local repository 
+
+`git clone <ssh>`: initiate a link between the remote repository and your computer : automatically create a .git local repository and bridge it to the remote repository.
+
+## commits
+`git add file_name`: add the file to the staging area
+
+`git commit -m "meaningful message"`: to save a version of the file on git (.git file in local repository). It should be followed by a meaningful message: 
+  - why was the file changed
+  - how this addresses the issue
+  - effects 
+  - limitations of the change
+
+ Pressing commit without using -m will open the editor, which allow you to give a meaningful message on multiple lines.
+
+ Commit can be used on multiple files that are in the staging area (we can `git add` files without directly `git commit`), to have one unified meaningful message for related changes in different files, so to reduce repetitive messages. 
+
+ `git commit --amend`: if your commit has not been pushed yet, this command allow you to edit its message.
+
+`git show <commit ID>` and `git diff <commit ID1 (old)> <commit ID2 (new)>`: show the difference in the files between two different commits
+
+## push and pull
+`git remote add origin <ssh>`: create the bridge between my local git repository and the remote github repository 
+
+`git push`: to send the local git repository to github, after bridging the two.
+
+`git pull` to retrieve remote repository to local repository (if someone else changed the github repository, *i.e.* update to the software)
+
+## check-up
+`git status`: check in which conceptual areas are the files: files have been modified but not staged (located in develop. area and local repo.), staged for commit (in staging area) and untracked (not added to git yet)
+
+`git log -n`: list n last commits done to the project 
+
+## go back
+`git revert <commit ID>`: go back to a commit
+
+`git reset --hard <commit ID>`: permanently delete further commits
+
+`git bisect`: binary search through commits to identify the specific one where the bug happened
+
+## branches
+
+`git checkout -b <branch name>`: create a new branch 
+
+`git push -u origin <branch name>`: link the new branch to main
+
+`git merge <branch_name>`
+
+`git stash` and `git stash pop`: temporally save changes in a branch locally w/o needing to add, commit and push
+
+## tags
+
+`git tag -a <tag> -m "my version 1.4"`: to tag the current commit and branch where you are located, will be available on github with its corresponding zip file once pushed. It is used to tag different versions of a project (v1, v1.2 etc). You can add many tag to the same commit.
+
+`git tag <tag> <specific commit ID>`
+
+`git push --tag` 
+

doc/dictionary

@@ -0,0 +1,47 @@
+# Dictionary of Git/GitHub concepts
+- Git: Timeline of your project
+- Github: The way to store online
+- 
+# 4 Conceptual areas
+- developing area: in your computer, the folder where the project is developed
+- staging area: place to prepare the commit (transition between develop. area and local repo. via `git add`). it allows to commit file A and B that are related in the project at the same time, as you can wait for file A and B to be in the staging area before commiting. 
+- local repository: where the file version is saved on git after `git commit`.
+- remote repository: the remote server where the project is saved (usually on GitHub). You can send commits from the local to the remote repository using `git push`
+
+# Fork and Clone
+When you are not a collaborator of a remote repository, you can clone it but cannot push/pull commits as you do not have authorization. you can neither push it to yout own remote repository. If you still want to use a remote repository that interest you and modify it, you can **fork** it on your own remote (github) repository. It is like cloning a remote repository but remotly. You own this new remote reposity, you can clone it locally and push/pull to your remote repository. 
+
+It is like starting a new project, but not from scratch, and forking it will establish a link with the owner, aknowledging its initial contribution, exactly like a citation.
+
+With collaborators, by forking and not cloning the remote repository, it allows to maintain only one repo and each changes need to be accepted by the owner --> less branch management.
+
+
+# Managing sensitive files on your local repo
+Using `.gitignore` file, you can list the different files of the project that should be ignored by git (*i.e.* not tracked), *e.g.* datasets, intermediate files
+
+# Error management 
+If I want to go back to a previous commit because I accidentally changed the file, I can either use `git reset --hard <commit ID I want to go back to>` but that would delete permanently all the following commits, which is dangerous.
+
+I can also use `get revert <commit ID I want to remove>` which will create a new commit that go back to where I want, but I can still access the commit I removed if I want.
+
+If there is a bug in your code and you cannot identify where it happened, you can use `git bisect start`to start a binary search through your commits. You specify a commit that you know already contains the bug (`git bisect bad <commit ID>`) and a previous one that was good (`git bisect good <commit ID>`). It will then ask you if another commit between these two timepoints is good or bad (hence binary). After a few iterations, it should find the specific commit where the bug happened.
+
+# Branches
+If you create a branch it is mirroring your main branch. You can make changes in your side branch without changing your main. you can create a new branch with `git branch <branch name>` and got into it with `git checkout <branch name>`or `git checkout -b <branch name>`
+
+then you can modify a file in that branch and push that to the remote repository. The first time you push (after `git add`and `git commit` in the new branch, you need to link it to the remote with `git push -u origin <branch name>`).
+
+you only have one actual version of a file in your local repository, but the .git file stores the versions of all branches you have locally. when you `git checkout`to a branch, it changes the version of the file and you can change this specific version (this branch) with add and commit.
+
+Rather than using `git add`, `git commit`and `git push` to store changes made in one branch to the remote repository, you can store them locally using `git stash`. It takes a snapshot of changes within one branch, which allows you to quickly checkout. Then, you can come back to these changes using `git stash pop`.
+
+# Conflicts while merging
+You can merge side branches with the main using `git merge <branch_name>`. If there are conflicts, you need to change the files conflicted as you think is best to blend the two versions, then add and commit the new version of the file. It will automatically merge the branches afterwards.
+
+# Github editor
+By pressing the `dot key` of your keyboard when you are on your github page, it redirect you directly to the github web editor, which is basically VSCode. It allows you to not clone each repository locally to modify them.
+
+# Issues
+On github, you can assign issues to collaborators, *i.e* specific problems in the files that need to be addressed. To link to a specific line in your code, you just need to go to the code file on github, click on the line number, and copy/paste the given URL in the issue message.
+
+

doc/documentation

@@ -0,0 +1,66 @@
+#dictionary
+
+- Git: git is your own timeline of your project
+- GitHub: this is the online repository of all timelines as a backup
+
+#COMMANDS
+    -git commit meassage:
+        Why your change
+        How you did it
+        Effects that it has
+        Limitations it has
+    - commit command:
+        git add file
+        git commit -m "message"
+        Note: if you do git commit then an editor will open to have a more extensive message
+    - check where your files are stored:
+        git status
+            to be comitted: changed added but not committed yet
+            not staged: tracked before but more changes not added yet
+            untracked: never tracked before, it is a new file that need to be added
+
+
+# four areas
+    Area 1
+        Developping area: your own project in your own folder
+    Area 2
+        Staging area: place to prepare the changes. This when you do git add, your changes are organised in this step
+        why using the staging area? this will improve the commits and allow you to organize the commits logically, if you have mulitple changes you can add according to a meaningful logic in stead of committing all at once
+    Area 3
+        Local repository: this is where your timeline exists, it is located in your folder as .git
+        this is the place where your changes go to after git commit
+    Area 4
+        github repository: the online repository; backup of all your timelines
+        note you can only delete, rename the repositories that you own (the one you have created)
+        you can push and pull for repos that you are invited to collaborate with
+
+# other files
+    readme file
+        the presentation of your project
+    .gitignore
+        ignores the files that don`t need to be tracked in git, like large data
+        eg: *.csv add also the .gitignore itself
+
+# bugs solving
+ if github complains about the ssh, you need to update the ssh
+
+# branches
+to be used to collaborate; to experiment
+
+# tagging
+you can tag the working version to keep the commits highlighted as working versions
+use git tag, tags are not automatically pushed to git hub , you have to push the tags to github
+in github, you can download the tagged version, it is under release and people can just download the releases
+
+# forking
+you create a remote copy ( >< clone; where you create a local copy>)
+cloning is creating a copy from the github repo to your local computer, but you only are allowed to push and pull if you are owning the repo or a collaborator
+once you fork a public repor, you can clone it from your repo to your local computer
+you can use the forking as an alternative to branches and wokring together
+
+# github nice features
+you open vscode directly in github by going inside a project and press . 
+you can also create issues, within the document pressing right button on a certain line
+or in the issue tab in github
+and you can assign to colleagues
+

environment.yml

@@ -0,0 +1,34 @@
+name: micro_cred
+channels:
+  - defaults
+  - https://repo.anaconda.com/pkgs/main
+  - https://repo.anaconda.com/pkgs/r
+dependencies:
+  - blas=1.0
+  - bzip2=1.0.8
+  - ca-certificates=2025.9.9
+  - expat=2.7.1
+  - libcxx=20.1.8
+  - libffi=3.4.4
+  - libgfortran=5.0.0
+  - libgfortran5=11.3.0
+  - libmpdec=4.0.0
+  - libopenblas=0.3.30
+  - libzlib=1.3.1
+  - llvm-openmp=20.1.8
+  - ncurses=6.5
+  - numpy=2.3.3
+  - numpy-base=2.3.3
+  - openssl=3.0.18
+  - pip=25.2
+  - python=3.13.9
+  - python_abi=3.13
+  - readline=8.3
+  - setuptools=80.9.0
+  - sqlite=3.50.2
+  - tk=8.6.15
+  - tzdata=2025b
+  - wheel=0.45.1
+  - xz=5.6.4
+  - zlib=1.3.1
+prefix: /opt/anaconda3/envs/micro_cred

ref/References.MD

@@ -0,0 +1,7 @@
+#### REFERENCES ####
+# git folder structure
+https://medium.com/code-factory-berlin/github-repository-structure-best-practices-248e6effc405
+
+https://medium.com/@tcij1013/best-practices-for-organizing-git-repositories-61e4538c3900
+
+https://softwareengineering.stackexchange.com/questions/86914/whats-the-best-structure-for-a-repository

src/code.py

@@ -0,0 +1,2 @@
+# here i can make some code like 
+print("hello world")