Git Workflow

In this episode we talk about keeping our projects together with OneDrive and eventually upgrading to git for full version control.

Segment 1 - Starting Without Git

• We used to use OneDrive to keep each other on the same page
• We had the same OneDrive directory sync to our computers so that our work would carry over
• However, this is not proper version control and therefore a bunch of conflicts would happen if we were working on the same projects, luckily most were minor and just required someone save their work again
• This solution did work for us, however, and we used it for well over a year with only a few major sync issues - which is pretty good for a program that’s not meant for version control
• To this day we still use OneDrive to keep some common files around, like graphical assets, however, our projects are not housed there anymore
• Our experience with using OneDrive rather than a proper version control did show us that it is possible to get started working as a team, even without the “industry standard” tools (in this case git)
• This is especially true if you work on projects yourself, or don’t touch any of the same files as another developer, so you can still have reliable file access across various computers while you learn how to use git

 

Segment 2 - Transition to Git

• Working on your own is still a good time to learn and practice your Git skills. Even though it might seem like it’s slowing you down it really is just preparing you for the eventuality of working in a team environment and is something that is definitely going to come up during interviews and jobs
• Learn the basics first
  • Cloning - initial act of taking the repository from your git source to your local computer
  • Pulling - taking the changes from the remote (git source) repository is updating your local repository
  • Committing - This is an action that ties the current changes you’ve made in your local repository to a ‘commit’ object that you are able to label/message with references to the changes you’ve made
  • Pushing - Taking all your local commits and transferring them (pushing them) to the git source repository
  • Fetching - Updating your local git file with the current updates that are on the git repository (origin)
  • Branches - A system where you can create ‘branches’ that are essentially copies of your repository. This allows you to develop code ‘risk-free’ without touching what is referred to as ‘master’ (master-copy). Usually branches are used for feature development, and best practice is to create a branch for each feature and once that feature i complete to close that branch
  • Merges - This is a system in place to handle taking your current branch and merging it into another one (usually a master copy or a pre-defined integration branch). The trick here is to avoid working on the same portions of code in different branches as the merge will create a conflict that you will have to manually resolve
• These base core concepts make up most of the functionality you’ll need to know to at least have a good base and be able to integrate easily into any companies workflow
  • Sometimes learning specific workflow habits (like we’ll cover in segment 3) can pigeon hole you as almost every company has a different workflow and if you don’t understand the basic concepts it’ll be tougher to go from one workflow to another

Segment 3 - Workflow and Benefits

• Recently we’ve begun working in larger teams and that has pushed us to develop a Workflow
• This is just going to be a example of the one we developed. Other companies will use different approaches depending on project complexity, team size, technologies available, etc.
• Our branch structure is as follow:
  • No one codes in master, it is the production branch and only once the application is fully tested do we promote to master
  • The main development branch is called dev-integration
    • Here is where everyone's feature and design branches will merge into for testing
  • Every developer gets their own branch, usually just one at a time although there are a few exceptions if multiple large features are being worked on at once.
• Once a developer feels like they have a good section of their feature is done and ready for testing they will create a pull request
  • A pull request is a system within gits infrastructure to signify the attempt to merge branches
  • Usually it’s easier to use your git service (bit bucket, github, gitlab) as they have a UI designed for this feature
  • It allows the team to view all the changes that will take place during the merge, and gives them a chance to provide feedback in a thread style format
  • Once approved, the lead developer can initiate the merge
  • A developer does not need to initiate a pull request to merge dev-integration into their local branch as there are no consequences of that, they can just a do a git pull origin [branch name]
  • Pull requests also provide a good history on your project, as long as the team names their requests appropriately you can look back easily to when a feature when merged in
• Like I mentioned previously once everything is merged into dev-integration and thoroughly tested, a pull request can be opened into master. This will then be vetted by the senior developers/engineers on the project and merged, after which production deployment and dev ops can begin
• This is of course just a snippet of the whole process and there is plenty of nuance that occurs, the more you work with git the more appreciation you have for it usually

 

Useful Resource - API Marketplace

• https://rapidapi.com/
• A lot of the time app ideas require an external source of information or some sort of off-app computing in order to provide a useful service
• For example, a video game collection app isn't going to contain all the video games that have and will come out, otherwise the app would be enormous in size
• Instead when you search for a game to add to your collection, the app will call upon an API which will generally search a massive database of video games alongside other goodies like cover art, release dates, etc.
• Often times when people come up with an idea for an app, they'll back down from making it because their idea requires a lot of specific information, or needs some sort of machine learning involved.
• Luckily there are a ton of APIs out there that can usually help out with these types of needs, allowing developers to finish up their apps without filling in massive databases, and learning very complex things like machine learning
• Today's resource is an API marketplace called RapidAPI
• I found RapidAPI, or more specifically Mashape, when I stumbled upon a Hearthstone API that linked to it
• MaShape was acquired by RapidAPI a few years ago, so that's the correlation between them in case you're familiar with the MaShape brand over the RapidAPI one
• RapidAPI contains tons of APIs in their marketplace that range from movie databases, to facial recognition
• Each API has their own page that contains a bunch of useful information such as: popularity, average latency over the past 30 days, average success rate over the past 30 days.
  • Plus more technical things such as how to access the API in a variety of methods like NodeJS, PHP, and more
  • It also tells you whether the app is free, freemium, paid, etc.
  • You can even test our the API right on the page

  Web News - Multi-Device Workflow

• Working across different devices is getting easier and easier whether you’re using the Chrome Extension that was just mentioned, using one of the Microsoft Office apps with the Microsoft Launcher (quickly open from “recent activities” in the mobile versions of the Office apps), messaging people in something like WhatsApp across the phone and desktop, etc.
• Does this workflow open up new opportunities for progressive web apps that are responsive
  • You could be working in a PWA on your PC and have your phone automatically sync with whatever you were working on, and open up right where you left off with just a tap
• This sort of workflow also points towards a more unified OS future, whether that be with more integrations between OSs (ie Word on Mac), or actually consolidating different versions of operating systems (ChromeOS/Android)
• Microsoft added a Chrome extension that allows Chrome to access the Windows timeline
• With the use of the Microsoft launcher being able to pick up exactly where you left off on your comp is a major convenience

 

You can find us on...

Facebook | Twitter | Instagram

RSS | Patreon | Spotify

Medium | YouTube | GitHub 

Reddit