DEV Community

Cover image for Code management with Git and Github
Chinmay Joshi
Chinmay Joshi

Posted on

Code management with Git and Github

Git is the most powerful version control system coded in the history of humankind. The super-rich feature set of Git makes the code management straightforward.

So today, let's discuss how we can follow a simple structure to manage our codebase.

Initiate -

When we kick-off a new project, we create a repository on Github. Followed by setting up or creating a README.md file. Now, it can be a public or a private project.

create-new-repo


Collaborators and accessibility -

After that, we invite our collaborators to collaborate. Always setup access rights to the collaborators. For example, not everyone can merge pull requests. Only the code maintainers or core team members can manage the merging part.

add-colaborators


Forks -

Every collaborator gets their own cloned repository so they can work independently. When you fork a repository, the primary repository becomes the upstream, and the cloned repository becomes the origin. We push our code to origin/branch-name and then it's merged into the upstream/develop. I like to keep my primary repository clean; therefore I suggest a fork based approach for development.

fork-repo

Most commonly, forks are used to either propose changes to the projects or to use someone else's plan as a starting point for your idea.


Branching -

So, when a collaborator wants to work on something new, they create a new branch depending on the type of the work they will be doing. So that, they can work on their features or bugs independently without troubling the other collaborators.
When you create a new repository on Github, you get a master branch, by default. Usually, all the developers or maintainers create a new branch from master, names develop.

create-develop-branch

develop should be the primary branch for merging your features, bugs and enhancements.

  1. master - is a branch for production deployments.
  2. develop - is a branch where we merge the code from different collaborators.
  3. staging - is a branch in which we merge and test our code before going to production-level. Once we test all the functionality and the deployment cycle, we push/merge the staging code into master.
  4. branch with unfinished work - When any collaborator leaves the organisation with incomplete code, or if he/she wants to transfer his/her ownership to someone else, it's a good thing to create a new branch on parent repository with his name. So the other collaborator can pull his/her code from there. Branch name can be something like this, collaborators_name/feature/feature_name.

It's a good practice to have (only) these branches on the primary repository. So it stays clean.
On your fork, you can create a branch based on the type of work you are doing. We can follow a simple technique to identify branches in a better way,

  1. For a feature, feature/new-editor.
  2. For a bug, bug/time-zone-fix.
  3. If you have an open issue for this then, issue/:issue_number/issue-description.
  4. Any enhancement, enhancement/background-color-update.

Very simple, isn't it? These are the industry standards or common practice that developers around the globe follow.


Pull requests -

Once the work is done we create a pull request from our branch to the upstream/develop. Now, it's a good thing to have different things set up on your pull request.

  1. Reviewers - Reviewers are those people who are going to review your pull request. You can request more than one review to the pull request.
  2. Assignee - Assignee is someone who is currently working on the pull request. There can be more than one assignee.
  3. Description - explain what is the pull request about. You can add issue reference number to the description.
  4. Labels - Labels are the best way to add identification to the pull request. Github has already given important labels. Such as - bug, enhancement, feature, wontfix, help wanted. So that other collaborators can identify the pull request without even opening.
  5. Milestones - By adding milestones, you can track and filter your pull requests. You can find a detailed description over here.

pr-labels

Before merging the pull request, at least have two code review rounds with your peers. Usually, I like to apply different labels such as waiting for peer review, waiting for merge review, changes suggested, help wanted, ready for deployment to track the status of the pull request.
Other than that, I like to add different labels to know the type of the pull request. Like, feature, bugfix, enhancement.
You can create multiple labels to make your pull requests more identifiable according to your process.
The Github already predefines some of the labels.


Issues -

This is a very good place to keep track of your bugs and enhancements. You can integrate bug trackers to auto-create issues. Issues are shared between the collaborators where they can have a discussion about the solution.
There’s an assignees option, where you can tag different collaborators.


Releases -

Whenever you merge any pull request from staging to master, it's a release. Essentially it's a good thing if you can track your releases. Every time we merge code to the master, we increment the counter by one. Now, it's easy to track your versions. You can read more about Semantic Versioning here.

The simple explanation for generating a version number is, MAJOR.MINOR.PATCH

  1. MAJOR - significant releases and features.
  2. MINOR - When you improve existing functionality, improve code quality.
  3. PATCH - for minor changes, bug fixes.

This is how you can draft releases with Github. It's simple and useful!

Real world example is Bootstrap -

bootstrap-releases


Before merging the pull request, you can have different tools to make your code robust. Like,

  1. Run test cases on a cloud.
  2. Run linter to fix code quality.

Well, that's it! I have documentation for all the stuff that I mentioned. If you want it, write your email in the comment section below. I would be happy to share it with you.

Top comments (20)

Collapse
 
codevault profile image
Sergiu Mureşan

Great tutorial! It covers most features from GitHub that are often unused. I would like to see a coverage of automated deployment on GitHub since you already started talking about that :D

Collapse
 
joshichinmay profile image
Chinmay Joshi • Edited

Thank you CodeVault!

I am not so sure what do you mean by "coverage of automated deployment".

Do you want to see code coverage generated by your test suite?
Or the progress of current deployment?

You can check out code-climate. It produces test suite coverage for your code.

Collapse
 
codevault profile image
Sergiu Mureşan • Edited

I see a lot of projects that have a build status for the current version. And there is also a system that builds the project and spits out library/installers/executable files after each push.

Using that coupled with git tags in your commits you can release a new version of your code by just pushing to upstream.

A small tutorial on that would merge perfectly with the end paragraphs of this one, I think.

Thread Thread
 
joshichinmay profile image
Chinmay Joshi

Got your point. Maybe I will write a new blog soon about that.

Meantime you can check out travis-ci. Their documentation is pretty amazing. And it's simple to integrate with Github.

Thank you for your inputs.

Thread Thread
 
codevault profile image
Sergiu Mureşan

No problem mate.

Thank you as well, I will definitely check it out.

Collapse
 
scottishross profile image
Ross Henderson

Thank you for your explanation. This is by far one of, if not the best, explanation of GitHub I have seen.

I am looking into how to integrate GitHub into my team's flow, and I have not been able to figure it out until now. Thank you!

Collapse
 
joshichinmay profile image
Chinmay Joshi

Hello Ross. I am glad you liked my article. And, It's true that defining and following any process takes some time!

Collapse
 
gerchog profile image
Germán González

What a great post!!

I would like to learn more about where to create test environments (local or remote), how to proceed to test the code and things like that.

Thank you, I will be waiting the email.

gercho.gonzalez@gmail.com

Regards.

Collapse
 
joshichinmay profile image
Chinmay Joshi

Hey, thank you. :)
Check out travis ci for remote test suite setup.

Collapse
 
tux0r profile image
tux0r

Git is the most powerful version control system coded in the history of humankind.

Actually, that's Fossil.

Collapse
 
joshichinmay profile image
Chinmay Joshi

@tux0r !!! Honestly, I have zero experience with Fossil. I will look it up. Thanks though. :D

On a totally different note... Porcupine tree fan?

Collapse
 
tux0r profile image
tux0r

Too lazy to change my avatar after ten years. But "In Absentia" is phenomenal.

About Fossil: Read this.

Thread Thread
 
joshichinmay profile image
Chinmay Joshi

Yes, "In Absentia" is phenomenal!
And, thank you for the link.

Collapse
 
ofirmeg profile image
Ofir Meguri

Good article

Collapse
 
joshichinmay profile image
Chinmay Joshi

Thank you!

Collapse
 
raminahmadi1986 profile image
Ramin Ahmadi

Thanks for your great post, I’d like to have the documentation
Ramin.ahmadi@live.com

Collapse
 
godswillokokon profile image
OGcodes

Great tutorial, I would love to have the documentation, here is my email Godswillokokon3@gmail.com

Collapse
 
davedodea profile image
Dave O'Dea

Thanks and really nice coverage of code management via GitHub. Good work 👍

Collapse
 
joshichinmay profile image
Chinmay Joshi

I'm glad you liked it Dave!
Thank you.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.