Intro to git feature branch workflow

okay I'm back now I'm going to talk about to get work flow so there there are a lot of different workflows you can use with git and github I'm just gonna talk specifically about what we've decided to do and show some examples I do want to bring up another diagram yeah there's this post so I've built that diagram that you just saw but that was heavily heavily based on this article called a successful get branching model and in this article Vincent lays out basically how things are done you have your develop branch which is have the latest and greatest features you have master which represents what's in production right now what our users actually using you have feature branches which are branched off of developed to implement specific features and then you also have hot fixes so a bug is found in production but you're not ready to release other features into production so you have a branch specifically for fixing bugs the way all this works I'm going to show with actual get but I do want to use my diagram here so the main idea here is that work can be done in parallel so if you have multiple features that your developers are working on that don't all depend on each other and even if they do they could be happening at the same time but they can happen in parallel so here we have feature branches so basically any piece of work that a developer is going to do they create a branch based off of the develop branch using a specific name so in our case I have ax - 0 0 - so this is example 0 0 - if you look on our Trello board we have a powerup where every single card has a specific identifier so see a 36 see a 38 see a 48 each thing has a unique ID and the idea is when you create a feature branch you name it specifically after the card that you're working on so in this case if I was working on the history page I would create a feature branch called CA 41 ok so I created that branch and then I start work I work on it work on it work on it and then I create a pull request and say hey this work is finished please review it and then merge it into the develop branch so the way we have it set up is develop is the latest and greatest features this has everything that I said has ever been written for this app it's in the developed branch this may not be what the user sees because we could be working on new features that haven't been deployed yet but this is everything latest and greatest and if you check out any of the github repos so if you look at app mobile you can see that actually by default we have our develop branch as the main branch here and basically what that means is when someone clones this repo down they're going to get the develop branch by default and then also when someone opens a pull request it'll be against the develop branch by default and that's what we've chosen to do because we want develop to be all of the latest and greatest things the next thing is releases so let's say all three features a B and C have been merged into develop and they now exist on the develop branch but we want to deploy we want to create a release from there so what I have here is we would branch off of the latest develop which has ABC and create a new branch called version 100 and this is gonna be our first version so we create it and then merge that into our release branch so you can see on github we also have a really what we called it staging here but basically this is right before we're about to merge into master which is production only we bring things here to make sure that everything is working and good to go and so that would have been merged into staging and that creates a specific release then after oops after it's been merged into release we then set up a tag and a merge to get ready to merge into master and the idea is anything that gets merged into master is ultimately what is deployed we are going to set up some automation we're basically anything that gets brought into master will instantly deploy to the mobile app so the moment we merge in anyone that has our mobile app downloaded we'll get a pop-up that says hey version 1.0 point two is ready would you like to download it so we'll have that set up and these are basically just like swim lanes that protect things from going from one place to the next so protecting future branches from develop our code reviews and pull requests so before anything can be merged in we make sure that multiple people have eyes on it and then going from a version branch into release branch we make sure like is this working is this what we want to actually test as a release that's good and then before we merge into master we make sure okay is the production environment ready to accept this latest merge like have we set up all the environment variables is everything good to go and then we can merge it in and it all it all works it's beautiful it's a wonderful cycle of development the other thing to mention here are potential bugs or hot fixes so let's say that okay ABC got released but then we started work on feature D and feature E and both of those have are like ready to be merged into develop but they're not exactly ready for production just yet so we don't want to release those what we can do is create a branch for a specific bug fix we would branch off the previous release so this arrow is coming from ABC but really it would be coming from version one release so we branch off of it and then we merge that bug fix into it and that bug fix is what we push into releasing and to master this allows us to not have to push all of the features because they may not be tested yet so in this scenario we're saying that D and E are untested features that were not ready for production yet so we branched we create a branch that doesn't include those things includes the fix and we release that to production and now our users can benefit from that bug fix and then after that that F also got merged into about develop so develop has everything it has features DNA and the bug fix for F and then this eventually we would create a new release and then push all tenaris that to production this also shows using semantic versioning if you're not familiar with that you can check out semper org and basically if you've ever installed anything from NPM you've seen semantic versioning it has three numbers the two dots in it but it actually means something so the first number is the major version and typically you only ever change the first number if there are breaking changes in your library or in your source code in our case where we're not really creating something for someone else to consume like we're creating a mobile app so I'm guessing it's gonna stay at version 1 for a while the minor version or the second one here is for new features so anytime you add something that's not a bug fix or a hot fix it's a new feature you increase this number and the last one is a patch so anytime there is a bug fix that's like backwards compatible and it's really just fixing things you up this specific number so we're following that specific versioning when we create our release branches and we create our tags so this is how it all works I am now going to show it a real live example of how we would do this with github but I'll do that in the next video see you there

Channel: Coding Garden

Views: 72,444

Keywords: learn web development, debugging, live coding, live streaming, educational, how to code, css, html, frontend, learn javascript, backend, mechanical keyboard, learn node.js, vscode, lesson, full stack, debug, learning, javascript, web development, full stack web development, node.js, frameworks, beginner, full stack javascript, programming, coding, learn to code

Id: Lj_jAFwofLs

Length: 7min 50sec (470 seconds)

Published: Mon Mar 04 2019