Learning GitHub

[SinclairC]

My last Push request ended up with a notification on here and a chance to Pull it after a review of the code.

Just now, though, my push request seems to have been automatically added to the initial_commit branch without any chance for review.

Any idea what I did wrong?

I may have set it to push to initial_commit, instead of creating a whole new branch, but I thought I'd still get to do the whole "pull request" thing...

[SinclairC]

I guess you have to make a new branch each and every time you Push? Or target a branch other than the main one? For some reason I was under the impression that you could do it without necessarily using extra branches all the time...

[hyndgrinder]

The directive from gitHub is branch early, branch often. Then review what you want to merge back into the 'master' (which I messed up and is no longer available to us from the init_commit branch.

So when I did the unifyClasses branch, I started on the SinclairTests branch, and created a new branch, and named it unifyClasses. I then committed the changes, and pushed the branch back up. With the commit in the remote repository, I went to the gitHub site and created the pull request. I set it up to commit the changes to the SinclairTests branch (which did not have a pull request created against init_commit). So, once that merge finished, the init_commit would have been unchanged, and SinclairTests branch would have reflected the unifyClasses commit.

Before merge of the Pull Request 10 happened, I took the feedback from your 'review without merging', and started a new branch from the unifyClasses branch and called it NamingConventions. I completed all of my changes before you completed the unifyClasses --> SinclairTests Pull Request. So, I created a new Pull Request to merge namingConventions --> unifyClasses branches. So, now from init_commit, there is one main 'branch' and 3 nodes, 2 of which have Pull Requests outstanding.

But I wanted to research what you meant about static methods on the Util class vs. being with their own class, so I went back to the SinclairTests branch, and started a new branch called classMethods. So now SinclairTests has the only fork in the project. We later discussed and agreed that these methods were not appropriate for classes, but my IDE was stuck in a state with these changes. So I commited, and pushed the branch knowing I would not create a new Pull Request to merge it back into the SinclairTests branch, nor ultimately the init_commit branch. So there it sits, abandonded :( .

Don't fret for it, however, it did it's job helping me understand why we didn't want to go that way. So, I'm ready to return to whatever branch is going to be our go-forward branch. As you recall, last night we had some difficulty getting the PR's done. I incorrectly told you close PR 10, unifyClasses --> SinclairTests, and only worry about PR 12 namingConventions --> unifyClasses. Where I went wrong, is I thought PR 12 would end up on SinclairTests since that was the beginning of the branch, and all changes were predicated from that node. So, you merged PR12, and it ended up on unifyClasses, exactly as I built the PR. But, we'd already closed PR 10, which was how all of the changes were supposed to make it back to SinclairTests. With all of our discussion, I knew you were satisfied with the changes in namingConvention, unifyClasses, & SinclairTests, i.e. we could in fact merge back to init_commit. And namingConventions and unifyClasses have matching code because they have been merged back to unifyClasses. Then you created PR 14 (Latest Version) which sent unifyClasses back to init_commit.

In the end, I understand the branch early, branch often. theory. Like, every functional change should have a branch. (i.e. I want add a class, so I branch, add the class and statics, make sure it still runs, and then I push, and branch again for the next class I want to add). And it's best if you log the enhancement or defect as an issue in gitHub before you address it. This way we can share the decision-making process across the team. I know we're only 2, but I pretend like we're a big shop, and at any given time, I could be playing any number of roles. Sometimes, I'm the owner and I'm thinking about strategic decisions and profit. Sometimes I'm the project manager and watch the commits, and issues being tracked, setting milestones, and generally managing the progress through gitHub issues. Sometimes I'm the developer, creating code and going through a mentor review. No matter what role I'm playing in that moment, I try to think about that structure and how we'd have to communicate if I weren't 1 person. You probably think I'm too verbose at times, but I'm trying to do like 2nd grade English teacher said 'Use the question in your answer to ensure that if I didn't know what your question was, I could still understand your answer'. Scale that theory up to adults in a dev shop, sharing ideas, and being verbose becomes exceptionally valuable in the long term.

[SinclairC]

Yeah, it's gonna take some getting used to, working with another coder. Had to do it eventually, though. "Branch early, branch often" sounds good. I think what'll be hard is that I tend to jump around between tasks constantly. It keeps each individual task from getting tedious/monotonous because there's always something else I can work on for a while. That's not quite feasible when it comes to working in a team or using github though, because even if I jump around between branches that I've been "assigned" to, they all need to fit together at the end...

You probably think I'm too verbose at times

I think you explain things well and I don't mind listening. I can be pretty verbose too, except that with work it doesn't always come as naturally as with other things. I'll get there, though.

[hyndgrinder]

This project is less about the product and more about the learning. So, feel free to experiment. Different shops work differently. I expect that multi-directional pull is more prevalent as an indirect proportion to the size of shop. The smaller the shop, the more responsibility to the project as a whole, and the more freedom to drive your own schedule. That's just my guess. No one to offend on this project though, and managing the pulls is going to be shared worked (I manage your PR's, you manage mine). Don't forget, just because you branch and commit, does not mean you're ready to merge. Branch and commit is how you start a new task and park it. Merge is how we get an accumulation of changes back into 'master' branch.

So, branch early, branch often...