Intoduction
Whenever you are working on a project with your team there will probably be ideas about new features, optimization, or all sorts of stuff regarding your project. You can imagine what a mess it would be if everyone starts to make changes to the code without consulting with their team leader, or even push the changes directly into production. The GitHub Workflow makes the whole process of managing your project a hell of a lot easier.
Whenever you create a new app on SashiDo, we automatically create a FREE Private repository for every app on SashiDo in GitHub, so any information in this article is applicable to it and you can give it a try.
The GitHub Workflow
You can divide the GitHub workflow in 4 basic steps:
Creating a branch
Creating a branch helps you and your team test new ideas, add new features, applying a bug fix and so on, without making direct changes to the master branch. The newly created branch is a snapshot of the current branch you are in, but changes you make to it will not affect the master branch.
You can give the branch whatever name you want, but it's advisable to be descriptive, so your colleagues can know what's being worked on in the given branch. Here are some example branch names: refactor-authentication, user-content-cache-key, make-retina-avatars.
There’s only one rule you need to follow: anything in the master is always stable and deployable.
It's important to note, that when you create a new branch, you're creating a copy of the branch you’ve selected. For example, if you have two branches - master & development - if you're currently in the development one, and create a new branch, it will be a copy of the development branch and all the changes you’ve made to it.
Adding Commits
After you've created a branch you can start making changes to it. When you modify a file, you can commit the changes to the branch. Each commit has an associated message with it, explaining why a certain change was made. That way the commit creates a transparent history of what you did so others can follow up. Furthermore, each commit is considered a separate unit of change. That means that if at some point a bug occurs in the code or if you have a new idea on how to do things that’s better than your current one, you can always go back to where you started.
Opening a Pull Request
Pull Requests are a comparison of two branches. After you've made your commits you can open a Pull Request to start a discussion about the commits you made. Pull Requests are tightly integrated with the Git repository, so anyone can see exactly what changes would be merged if they accept your request.
Opening a Pull Request is fairly easy and it can be done at any given time. For example, you might have a very small amount of code but you want to share the idea with your team so they can give you suggestions or directions. After you’re pretty much sure that you’ve done all you can, you can open a Pull Request so others can view the work you’ve done and decide whether it’s alright.
You can even notify specific people using the mention system. That way, a specific person can be pinged that you would like to review the request so no one stays out of the loop. You can do that with the following syntax - @name.
Pull Requests are useful for contributing to open source projects and for managing changes to shared repositories.
Pull Requests are also very useful for the Fork & Pull Model. For example, your friend is developing an awesome application on SashiDo and you want to contribute to it. When you make a fork of your friend’s repository, GitHub creates a copy of its repo in your account. After you’ve made the changes and think that they might be relevant for your friend, you can open a Pull Request to start a discussion about them. If your friend likes them, he can merge the changes.
You can also consider using a Shared Repository model. That’s basically when collaborators are granted push access to a single shared repo and different branches are created when changes need to be made. In this model, Pull Requests are an awesome way to start a conversation regarding the changes you would like to make to the project.
Reviewing Pull Request & Merging
After you've made a pull request, your team may have comments or disagreements so you might have to change something and make further commits to your branch. Working that way ensures that nothing gets to production before it's well tested and approved. After everything is fine and your team accepts the changes you want to make, they can be merged with the master branch.
Deploying on SashiDo
What we’ve done for you on our platform is that when you merge/push to the master branch, your changes automatically deploy to SashiDo. That saves a lot of time, but you must be cautious because any changes to the master will be reflected in your app.
Don’t worry, because there’s an easy way to manage your workflow on SashiDo. For that purpose, you can have two applications - one for production and one for development. That way it will be much easier to collaborate with your team and define what access any given person has. For example, you can add new members to the development application. By doing so, you ensure that anything that's not tested or approved stays out of production. When everything is ready and good to go, the person responsible for changes in production can apply the changes to the production application.
It's always cool with video
Here is the official short GitHub Getting Started video on YouTube :)
And our short video how to start using the CloudCode with GitHub in SashiDo :)
Top comments (0)