Quiz
- What is standard for how often you should commit? Push?
Great question! The mantra is to "commit early and often". The idea is to have a granular record of changes. So, if you sit down and in the course an hour you add three features to your app, that should be three commits, rather than one that says "stuff I did today".
Of course, it's hard to have that discipline, at least at first. But think of it as a reward for checking off an item on your to-do list.
As for pushing to Github, you can do that when you have stuff to share. That might be less frequent.
It's also common to begin a session by doing "git pull" to see what your colleagues have to share with you (and to resolve any conflicts). But it's not required.
- What is the difference between saving a file locally using Command + S and saving changes using Git commands like git add and git commit? Why do we need both to make it work?
They are very different.
We save a file (Command + S) before running it. We run it to see if it works or has bugs. So, you might save a file a dozen or more times before you've debugged a new feature.
Once the feature is "done", you would create a new commit, by git adding all the files that are part of that new feature and then doing a "git commit".
- Besides codeberg and github is there anybody else that actually provides this kind of service or is it pretty much just a github monopoly?
Great question. I know of Bitbucket off the top of my head. A web search found this: git hosting services, which was thinner than I expected, but reminded me of gitlab.
Plus, lots of places do their own git servers. Ben Wood implemented that for CS 240 here at Wellesley.
- How do we fix a merge conflict? Will you go over that with us or should we consult the internet?
I will. I plan to cover Git in three steps:
- Git for one
- Git with collaborators
- Merge Conflicts