Git Workflow
Episode 30
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
<
Published on 6 years, 10 months ago