This evening, I've closed development on Release 0.2.0 of Link Checker which includes features to choose to:
Only show good links
Only show bad links
... and, as shown above, show the exit code of the app!
I want to talk a little about branches, merging, and what it does to a workflow.
For OSD600 Lab 3, we had to work with git branches, checking them out, editing within them, and merging them into the master branch.
Checking out and merging branches is great and I really think it works well in a project where one person is working in a group and is trying to fix an issue or add a feature. But when I'm working as a singular developer on a project such as this, I work very sporadically. Not only that, but I work from multiple different machines. Tonight I'm working on my laptop at my grandma's place on Thanksgiving. Last week I was working in my apartment on my desktop. If I'm working with localized branches, how am I going to work on issue 5 on my desktop and later on my laptop? This week that question dug at me and had me merging and pushing a half finished feature to GitHub so I can work on it later.
Later that week, I learned that you can upload individualized branches to GitHub so you can work remotely. Obviously missing this feature was a hinderance to the organization of the project and really a hinderance to the Lab. To submit the lab, I have to link the merge commit that shows the code that has the feature. This is difficult if I've commited multiple things to the project.
So one thing I've learned is that I need to use GitHub branches in the way they were intended - it's a great feature for git and next time I'll use it actually help keep my project organized.
I have a second thought about branches. The other evening I felt I needed to make a quick change to my code. But I had decided the issue was closed, how do I fix it? I can simply spend a few minutes writing, add, commit, then push, or I can open up a new issue, create a new branch, write my code, push my code, merge the branch on GitHub (I can do this locally), then close the issue with the merge. The first option seems a lot easier. I feel like issues and branching and merging are great to work on a bug or a feature, but if I want to quickly improve some code then I don't think it's conducive to my workflow to branch out. That said, I can also use a branch without creating an issue and creating a new branch really doesn't take more time than a couple seconds.
What I think the problem here is that when coding or starting to code, browsing GitHub is just bad for the workflow. I'm trying to browse GitHub to find issues to fix or write an issue that needs to be fixed. These are points on a todo list, or things I want to see before and after I code. When I'm actually in the process of coding or trying to solve a problem, I'm not trying to brawse GitHub.
Those were the big two thoughts I had about this lab and the way I added these features to the project:
- You have to use all the tools, including the ability for GitHub to hold multiple branches at once
- When working on improvements to code spontaneously, it's ok to not browse GitHub and create an issue, but I should really open a branch for improvements to keep them separate from the main.
Top comments (0)