LouisJenkinsCS
commented
7 years ago To ensure it comes in your emails: @bmeglathery @ktc45622 @TylerMutzekCS @dan0x19b
Open LouisJenkinsCS opened 7 years ago
LouisJenkinsCS
commented
7 years ago To ensure it comes in your emails: @bmeglathery @ktc45622 @TylerMutzekCS @dan0x19b
bmeglathery
commented
7 years ago Good stuff, I like it! If anyone is confused or needs clarification or help with something, PLEASE ask for help - no one is judging here! I ask questions all the time and you all thought I was best fitted to be group leader haha so there.
Source Control Management
Visual Diagram
Visual aids normally help a lot, especially when I have to explain things, so I have included one below. The boxes are repositories and arrows are directions in which changes flow through. The darker the shade, the more significance of the changes that go through it.
The Plan
The plan is that ALL changes should occur in our own branches, of which I'm going to be enforcing (as of this moment) a naming convention. It should Name-Development, where Name clearly is your first name capitalized. In the next example(s), I will be using my own, Louis-Development, in place for a generic representation.
Example
Lets say that want to make a few changes. If it is REALLY small, like a few lines of code, I should handle it first inside of Louis-Development. After I am sure it is ready to be used by other team members, it should then potentially be merged with Development. I will go over pull requests once we get there. Next, let us say that we have all followed this and are satisfied by what is in Development, if there is any doubt at all, it should first flow through Testing (which will be created on demand). Whether or not we go through Testing is up to what we've done. At the end of the week, when hours are due, we should (and I actually mean MUST) have something stable for Master.
Why
Its easy to follow this without first understanding WHY I am doing this. The reasons behind doing so is two-folder. For one, we enforce a much stricter coding standard and ensure no bugs get through by first going through Development. Second, it makes it almost trivial to rollback if someone's commit has caused a bug. You see, each pull request is a commit in and of itself, and like a transaction, it can be rolled back.
Imagine the following: 4/5 of us has contributed great code so far, but an unfortunate 1/5 of us accidentally sent in a bug that went unnoticed until now. At this point it is too late to 'undo' what he has done, because rolling back his would mean rolling back everyone's commits. So instead of having about 10 - 15 merges, we have 100+ individual commits (that could have been wrapped in a single merge) that need to be rolled back. Tragic.
Analogy
What I should see Louis-Development as is a 'daily' (or 'nightly') build, in that it is something that is pushed out once a day (although not mandatory). You can see what is in Master as a Weekly build, which is much more stable than a daily build. Stuff like that.