As mentioned in the project introduction, this week we're reviewing each team's git flow at the half way point so they get a picture of how well their project is going before review on Thursday. I can't stress enough how important it is for all projects to have a nice commit, pr and issue history!
It's not just a FAC thing or a nice to have - some employers take Git history into consideration when looking for employees. Also, once you get into the habit of keeping projects to a high standard and learn the common patterns of great Git flow you'll notice how much easier it is to jump into other people's open source modules or look over a project you worked on a few months back.
The project
You have a few commits and PRs in your project that are linked to issues so I know you know the right way to do it. I understand that as a group of three working closely together, it can feel weird reviewing each others PRs or assigning yourselves to issues, etc. But it's not just about now, it's about getting practice in now and learning to keep every future project to a high standard.
Some improvements for this week:
Link to issues - Only about half your commits are linked to issues, and even then sometimes there's mixed content within the commit that isn't really related to the issue. There are only two acceptable places to have commits that aren't linked to an issue: the initial commit and commits generated automatically by a merge from master. After that point every single commit/PR should be linked to an issue or issues that describe the tasks worked on.
Issues should clearly describe a task - If you're at a loss for issues to open, have a look at the project architecture and wireframe and raise an issue for every section of it before you start work. If you've drawn a nice architecture then it doesn't take long to convert each part into issues, and then those issues are a great place to jot down notes about the development process or things you think might work better. For example this week's back-end section could have issues for handling static file requests, handling api requests, searching through a large dataset and building an initial server boilerplate.
As mentioned in the project introduction, this week we're reviewing each team's git flow at the half way point so they get a picture of how well their project is going before review on Thursday. I can't stress enough how important it is for all projects to have a nice commit, pr and issue history!
It's not just a FAC thing or a
nice to have- some employers take Git history into consideration when looking for employees. Also, once you get into the habit of keeping projects to a high standard and learn the common patterns of great Git flow you'll notice how much easier it is to jump into other people's open source modules or look over a project you worked on a few months back.The project
You have a few commits and PRs in your project that are linked to issues so I know you know the right way to do it. I understand that as a group of three working closely together, it can feel weird reviewing each others PRs or assigning yourselves to issues, etc. But it's not just about now, it's about getting practice in now and learning to keep every future project to a high standard.
Some improvements for this week:
handling static file requests,handling api requests,searching through a large datasetandbuilding an initial server boilerplate.