GitHub is a code hosting platform for version control and collaboration. It’s designed around Git, a system for tracking changes in software code. It lets you and others work together on projects from anywhere. In this article we’ll take a look at the key concepts of the GitHub development workflow. Including working with repositories, branches, forks, commits, pull requests and merging. Let’s get started!
Version control is a system that helps developers track and manage changes to a software projects code. As projects grow, the need for version control becomes vital — especially in a collaborative project. We can work safely by using whats known as branching and merging.
Branching allows us to duplicate our source code (aka ‘the repository’), so we can safely make changes without affecting the entire project. Once the changes have been reviewed and approval is agreed upon, we merge our branch into the master to update our official code. If any bugs are identified— we have the option to revert back to our original code, as our changes have been tracked.
Git and Github are not synonymous! Git is a specific open-source version control system created by Linus Torvalds in 2005. It’s the program that actually tracks your changes, and ensures the entire code-base is available on each developers computer. GitHub however, is simply hosting your repositories (as well as providing some additional functionality).
Let’s get started! If you haven’t signed up for a GitHub account, go ahead and sign up here.
A GitHub repository (or “repo”) can be thought of as the root folder for your project. It contains all your project files and gives you the ability to access each files revision history. If you’re working in a team you can give other people access to your repository for project collaboration.
Lets create our first repository! Make sure your signed in to GitHub, then:
+
icon & then New repositoryIssues are how we track the tasks, enhancements, and bugs in our projects. They’re meant to be shared amongst your team to facilitate discussion for review as well as for managing task delegation. If you open an issue on a project managed by someone else, it’ll stay open until either you close it (for example if you figure out the problem) or if the repo owner closes it. When you create an issue, be sure to give a clear explanation of the task at hand. Let’s create an issue in our repository:
Assigning an Issue
We need to assign issues so our team members know who’s job it is to handle the task!
Let’s resolve our first issue! We want to Setup GitHub pages. You can read about GitHub Pages here. But for now, our focus on completing the task:
Closing an Issue
Now you’ve completed the task — you can go ahead and close it! You can delete an issue on GitHub, however closing it tells your team members that the task has been completed. To close:
Now that we know how to work with issues, it’s time to look at the GitHub Flow. Simply put its a workflow where we can experiment with new ideas safely, without the risk of compromising our project. This is primarily achieved through the use of branching.
By default, our project lives on the master branch — any changes to the master will update directly to our project (This can be dangerous is you haven’t properly reviewed your changes!).
When we want to experiment with a new feature, or even fix an issue, we create a new branch on the project. The branch will initially be a duplicate of your master, now when you make changes —they’ll reflect only on the branch.
While working on changes, you’ll commit the changes to your branch. When you’re satisfied that the changes are complete, its time to open a pull request. From here your team will discuss and further refine the project changes. Once the changes have been approved, the branch will be merged onto the master branch. Let’s go through an example of this process now!
Creating a Branch
Branch: master
in the drop-downNow that you’ve created a branch, you can modify your project without changing the deployed master
branch.
A note on forks — A fork is different to a branch in that it allows you to clone another repo in your own account. It essentially allows you to start a new project based on a previous project.
Committing a file
Now we can safely work within our branch, let’s create a file and make our first commit.
You’ve made your first commit! The next step is to share the changes with your team via a pull request.
Opening a Pull Request
A pull request is where we share our proposed project changes with our team — with the intent on discussing & revising them before applying the changes to the master
branch.
Your team members now have the ability to discuss and review your proposed changes. Once everyone is happy and the changes are approved— it’s time to merge to master.
Note: If you forked a repo and made changes, you can create a pull request to merge your changes from there as well.
Merging a Pull Request
And that’s it! You’ve learned how to work collaboratively on projects using GitHub. GitHub is an amazing tool to take advantage of! You can now create repositories and issues, create branches, fork projects and make commits, submit pull requests for review, and merge to the master branch. Not bad!
I hope you found this article useful!
#Github #JavaScript #Tech #Front End Development #Git