Do you have issues with commitment? You won't after completing this homework!
In the last two homeworks, you modified three - example.py, task1.py and task.py. Notice that they are highlighted in the file tree in orange, meaning that they have uncommitted changes. To go back to our computer game metaphor, we have made progress in our game but we haven't made a save game. In Git parlance, we are going to make a commit.
It is good practice to make a commit after making a significant milestone or segment of progress (like completely a homework). You can make them as often or as infrequently as you like, but it's good to keep a regular schedule.
A commit is like a milestone involving several files of our choice. In the future, once we have made several subsequent commits involving these files, we will have the ability to return to (or 'checkout') any earlier commit at any time, just like loading up an old save game. It's like time travel, but for code.
The first thing to do is to look at the Source Control panel. You can switch to this clicking on the button the left (highlighted in red) or by pressing Ctrl+Shift+G. We should see three files which have been identified as having uncommitted changes - click the plus (+) button next to each one to (highlighted in yellow) to 'stage' these changes. Files which are staged are part of a 'package' ready to be committed. I give an example of a staged file with a blue arrow pointing to it in the below image.
Once all three files have been staged, we need to give to write a commit message in the box above the green button. Try to think of something meaningful to put in every commit message: this is a real art. In the image below I show some examples of very bad almost meaningless commits. Here we are committing the changes from the last two homeworks, so many enter something along those lines.
One all that is done, simply click the green button to make the commit. At this point, we have only made the commit 'locally' i.e. they only exist within your Codespace (or on your hard-disk if you are working on your computer). We now need to push these changes to the remote repository, that is the GitHub servers. To do this, simply click the Sync button which should now have appeared. A message should appear asking if it is OK to make a Push and Pull operation, to which you should say yes. Don't worry about what a Pull operation is at this point, but it is pretty much just the reverse of a Pull i.e. it brings any changes which might exist on the remote server to our local workspace (currently there are none).
And there we have it! You just made your first commit and pushed the changes to the remote server. This is no minor achievement, you have just learned how to do the most important task using Git. There are other things still to learn about using Git of course, but this is the biggest and most useful part.
The last thing in this homework to do is to go to the web page of the repository and see the changes appear (you need to be on your branch of course).
Do you have issues with commitment? You won't after completing this homework!
In the last two homeworks, you modified three - example.py, task1.py and task.py. Notice that they are highlighted in the file tree in orange, meaning that they have uncommitted changes. To go back to our computer game metaphor, we have made progress in our game but we haven't made a save game. In Git parlance, we are going to make a commit.
It is good practice to make a commit after making a significant milestone or segment of progress (like completely a homework). You can make them as often or as infrequently as you like, but it's good to keep a regular schedule.
A commit is like a milestone involving several files of our choice. In the future, once we have made several subsequent commits involving these files, we will have the ability to return to (or 'checkout') any earlier commit at any time, just like loading up an old save game. It's like time travel, but for code.
The first thing to do is to look at the Source Control panel. You can switch to this clicking on the button the left (highlighted in red) or by pressing Ctrl+Shift+G. We should see three files which have been identified as having uncommitted changes - click the plus (+) button next to each one to (highlighted in yellow) to 'stage' these changes. Files which are staged are part of a 'package' ready to be committed. I give an example of a staged file with a blue arrow pointing to it in the below image.
Once all three files have been staged, we need to give to write a commit message in the box above the green button. Try to think of something meaningful to put in every commit message: this is a real art. In the image below I show some examples of very bad almost meaningless commits. Here we are committing the changes from the last two homeworks, so many enter something along those lines.
One all that is done, simply click the green button to make the commit. At this point, we have only made the commit 'locally' i.e. they only exist within your Codespace (or on your hard-disk if you are working on your computer). We now need to push these changes to the remote repository, that is the GitHub servers. To do this, simply click the Sync button which should now have appeared. A message should appear asking if it is OK to make a Push and Pull operation, to which you should say yes. Don't worry about what a Pull operation is at this point, but it is pretty much just the reverse of a Pull i.e. it brings any changes which might exist on the remote server to our local workspace (currently there are none).
And there we have it! You just made your first commit and pushed the changes to the remote server. This is no minor achievement, you have just learned how to do the most important task using Git. There are other things still to learn about using Git of course, but this is the biggest and most useful part.
The last thing in this homework to do is to go to the web page of the repository and see the changes appear (you need to be on your branch of course).