Strange week in all, especially after last week and the new found focus I have on my future plans and desires. It feels like I have not got a lot done however there has been a lot of new knowledge gained due to the decisions I have made.
Last Weeks SMART Target
So a little to update on regarding this. As it is a more on going target its going to be one I am working on for a while, more than likely much further than just this modules content, so I need to make sure I am tracking progress on it.
The target was
Utilise the rapid ideation 2 project to create a boilerplate project to be used in the creation of hyper casual games for my own company. This project will be shared and stored on Github and completed by the project deadline (with on going development when needed).
And I actually focused on the second sentence more than the first this week spending a lot of time getting back into the swing of things with Git and Github.
This Week
I spent a lot of time getting some refreshers in Git and finding out about some new innovations within the area. One thing that I wanted to make sure about, because I had experienced problems with it before, was ensuring my work flow was correct. My previous use of Git had been troublesome at best, especially when placed in a team based environment, because it seemed like it was always prone to breaking in some way. This meant I had to delve in to the command line to fix issues that took a lot of my time.
I recalled an article by Driessen (2010) that I read a few years back that explained how to effectively use Git within your work flow and utilise branching in order to make sure that the main course of development was not affected by other issues you may encounter during development.
I am glad I sought out this article for a refresher because the author has added a note of reflection which pointed me towards a newer guide from Github called Github Flow. This discusses the use of branches for development that are then incorporated into the main development master through Pull Requests. Essentially you are working on something and telling the master project to take a look at it and see if it wants to include it.
This to me seems like a good model to adopt, rather than the one I used before which one just to use the master repo for all development, it will be especially helpful for team based projects.
So I am glad I went back to the start again with Git, it does not seems as scary as my previous experiences with it and I have managed to get my repo set up for Rapid Ideation 2, and both my machines set up to work on it with one being a branched version of the main repo.
Next Weeks SMART Target
To continue working towards this current SMART target. Obviously I will be focusing on the first sentence now.
Utilise the rapid ideation 2 project to create a boilerplate project to be used in the creation of hyper casual games for my own company. This project will be shared and stored on Github and completed by the project deadline (with on going development when needed).
References
Driessen, V., 2010. A successful Git branching model. [online] nvie.com. Available at: <https://nvie.com/posts/a-successful-git-branching-model/> [Accessed 25 July 2021].
Guides.github.com. 2020. Understanding the GitHub flow ยท GitHub Guides. [online] Available at: <https://guides.github.com/introduction/flow/> [Accessed 25 July 2021].
Figures
Featured Image: Photo by Donald Teel on Unsplash
0 Comments