Slide 1 ----------- Part 1: In this section, we dip our toes into version control using Git and Github. We also show you how to submit your assignment and check the submission on SkillPies. Slide 2 ----------- Part 1: To submit your assignment, you need to stage and commit it to your repository and then push it to Github. Part 2: In Git, the term "staging" relates to grouping your changed files based on the functionality you are working on. For example, changing the look of the button, or changing the calculation of the tax formula. Part 3: Once the files are in the stage, you commit them to your repository, creating a named point in time which records all the changes to your files up until that point. These changes can be viewed for posterity or even rolled back. Part 4: Last, you can share your changes with the rest of the team by pusing it to a remote repository. Part 5: The repository then notifies your project members that can pull the changes to their computers. Understanding the difference between these three actions is crucial for effective version control and collaboration in Git. Let's take a look at an example! Slide 3 ----------- Part 1: Let's talk about how you can safely create different versions of your files. Imagine that you currently have six files in your project. Part 2: You changed the first five files while working on your project. But your changes relate to two things you worked on. Part 3: For example, the first change would relate to login functionality Part 4: and the other changed the look of your task list. Therefore, you would like to separate those two changes into two distinct commits. Part 5: This is where the staging area becomes essential. You can choose to stage-specific files or even individual parts of files, which gives you greater control over your commits. For instance, start by staging the first three files. Part 6: Staging is also useful for tracking changes in your files. When you’re satisfied with a particular change and want to experiment further, you can store the file in the staging area. This allows you to easily compare any future modifications against the version you’ve staged. Part 7: Once you are happy with all your changes and you staged all the files, you can commit them to your repository. This creates a new record, which can be reviewed or rolled back in case you change your mind in the future. Slide 4 ----------- Part 1: Let's commit to the repository the second set of changes. Part 2: First, we stage them. Part 3: Then, we create a new commit. We did not mention that each commit must be accompanied by a message briefly describing the purpose of the committed changes. This time, we say that we added a Google login. Let's take a look now at how we can share our changes with the rest of the project team. Slide 5 ----------- Part 1: Until now, we only worked on our computer with local files. This reflects the distributive nature of Git, where every developer has a complete copy of the repository, making the process secure and almost foolproof. Part 2: But, when we want to share our files, we must use a remote, shared repository. In our case, we use Github as our repository provider. Other providers, such as Gitlab, exist, and you can even host your repository server, but for now, Github will do. Part 3: To share our files with the rest of the team, we need to push the changes to Github. This will copy all the commits we have made locally to the remote repository. Slide 6 ----------- Part 1: The rest of the team, or anyone who has access to the repository can pull the changes to their computer, to obtain the newest version of source files. Part 2: For example, if commit 3 and commit 4 appear in the repository, Part 3: we can pull these changes to our local computer and work with the project's latest version. Slide 7 ----------- Part 1: To store your changes in the repository, you need to add changed files to the stage, selecting them and clicking on the plus icon. Then, we need to add a commit message summarising the list of our changes. Clicking on the commit button saves the changes to the local repository. Then, you can Sync, or Push and Pull changes to and from the remote repository. Slide 8 ----------- Part 1: Once you submit your files, Github Classroom will run automated checks to see if your solution is correct. There are multiple ways you can check if your solution passed all the tests. Part 2: The easiest way is to run "pnpm test" in Visual Studio Code and make sure that all tests turn green. Part 3: You can also check out test results in SkillPies. First, make sure you specified your Github user name in your bio on your profile page. Part 4: Then, you can just refresh the assignment page, and on the top you will see one of the three possible messages. First, the yellow message tell you that you have not yet pushed any of your changes to the remote repository and the system did not run any tests. Part 5: The red message tells you that at a least one of the tests failed and you must re-visit your solution. Part 6: The green message is a thumbs up that your solution is correct and you can continue with the next exercise. Part 7: You can also visit your repository on Github and see the test log there! First, you have to log in to Github and find the assessment repository. Then, in the "Actions" tab, you will see all the test runs that Github performed. Find the one that interests you and explore the log. This is actually a CI pipeline which we will talk about later in this course. With this assignment you are officially no longer a rookie and let's start doing some real React work!