- If you don’t know what are Git and GitHub yet, it is recommended to read this presentation. Even if you know, it can be handy.
- Also, it is recommended to work with one of these two workflows: first, second. You can read here how to write correct commit messages.
- More useful articles are here.
- Create a GitHub account if you still don’t have one 😆
- Follow the link to the lab.
- Choose your name and surname from the list. Please choose your name, not of another person.
- If you want to work in a team, choose your team.
- IMPORTANT! Team name convention: surname_surname...surname. Sometimes, it’s forbidden because of very long surnames - then use not more than six first letters of each surname.
- I hope you will enjoy 😇
That is just an example of the project structure. Using all of the files or directories in every lab work is unnecessary, but you must read all README and understand how to care for your code. Also, it is forbidden to change the project structure or the cmake folder.
- Comment your code correctly, and write good documentation.
- Write on the CMS in the task submission you submitted on the GitHub Classroom.
- As we all have nicknames in GitHub, it is essential to write the correct README.md file in the root directory!
- For any questions you can ask your assistant.
- You can find your labs anytime by this link.
So, you will see the following. PLEASE, choose your name and surname; it will save time for you and us:
And well done! Your repo was created! You can see the deadline and the link to your working repo here.
and in your terminal, go to the Downloads directory and clone a repo to that dir.
“`shell
cd ~/Downloads
git clone [copied link here]
Now, you can do your lab work. Please use the `README.md` to specify your lab, team, and variant and describe what your code can do. Use the project structure and write good documentation for your code.
### Workflow
You can use one of the workflows proposed earlier or just make commits and pushes, **but** don’t make one commit for all labs. It will be better for you to make changes if you commit after each implemented feature.
For example:
“`shell
git add .
git commit -m “add basic String implementation with dynamic memory allocation”
git push -u origin master
After your code is pushed to the server, the script will be tested for compilation using the GitHub CI feature.
Important! The folder .github contains files responsible for that, so do not touch them, or it will be penalized with points.
The CI status can be one of three: In process (yellow), Succeeded (green), and Failed (red). See the pictures below.
If your program has the status Failed - it will not be checked. It is automatically treated as not submitted. Please consider this before the deadline and ask your teacher and assistants about possible problems. If your code is In process for too long (a few hours) - immediately contact your assistants - it is not yours but their issue, and they will fix it. If your code is Seccedded - everything is Okay.
Before writing to the teacher or assistants, you should check what is wrong with your code.
It can be done by clicking the Action button
And there, you will see the output with some errors - the same as in your compilation window on your local PC.
Please fix whatever is written there and submit the code again.
