DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for My Experience With GitHub Topic Branches
Samina Rahman Purba
Samina Rahman Purba

Posted on • Updated on

My Experience With GitHub Topic Branches

Thoughts πŸ’­

This week I learned something new about GitHub – using topic branches! And not just that – I also added two new features to my static site generator, rwar. Rwar is a simple static site generator written in Python and I keep improving it every week by implementing one or two new features, along with updating all its documentation and debugging anything that might have broken in the process. If you are interested in Python, I encourage you to check out rwar. Fork it, clone it and test it out! Building this project paved a path for me to learn Python and trust me I have learned so much in such a short time! The best way to learn something is to start building a project with it. Yes, it requires a greater learning curve, and there is a greater chance of breaking stuff in the process, but through getting hands-on, the learning happens so much faster.

Working with GitHub topic branches πŸ”§

  • I started the process by first filing issues in my repository.
    Issue 9 provided a short description about implementing a –l flag, which indicates the language to use when generating the lang attribute on the root <html> element.
    Next, I filed issue 10 which provided a short description about supporting horizontal rule in Markdown. This means that the Markdown --- will be converted to <hr> in the generated HTML.

  • Then, I created the topic branches in the following way:

$ git checkout main
$ git checkout -b issue-9
$ git checkout -b issue-10
Enter fullscreen mode Exit fullscreen mode
  • Next, I started working on my code! I implemented each feature separately as I had a clear idea of how to implement them. Each feature required only a few lines of code to be added and I managed to do them quickly without any issues.

  • After all the implementation was ready, all I had to do was merge! This went smoothly without any merge conflicts. Here is an example of how that looked like:

$ git checkout main
$ git merge issue-9
Enter fullscreen mode Exit fullscreen mode

Helpful links

Issue Closed by
Issue #9 7546901
Issue #10 9eae23b

What I would do differently next time ❓

I realized that Git is powerful as it allowed me to work on different features with different versions of the code simultaneously existing at the same time. However, as strange as it sounds I wanted to experience merge conflict to see what it looks like and how I can resolve it. However, I believe as I start working on bigger and more complex projects I will eventually face those dreaded merge conflicts.

I would also change the names of my issues to something more descriptive Instead of just labeling them as issue 9 and issue 10. Perhaps, I could name them according to the feature being implemented.

Some more thoughts πŸ’­

I am really looking forward to Hacktoberfest! Although I suffer terribly from imposter syndrome and deeply fear pull requests, I am ready to give it my best shot.

Top comments (1)

Collapse
 
batunpc profile image
Batuhan Ipci

Let's ace Hacktoberfest!

Hey 😍

Want to help the DEV Community feel more like a community?

Head over to the Welcome Thread and greet some new community members!

It only takes a minute of your time, and goes a long way!