My Experience With GitHub Topic Branches
Tags: python, opensource, github, git
Published: 2022-09-30 04:29:21


## 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](https://github.com/saminarp/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](https://github.com/saminarp/rwar/issues/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](https://github.com/saminarp/rwar/issues/10) which provided a short description about supporting [horizontal rule](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hr) 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
```

- 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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts). Here is an example of how that looked like: 
```
$ git checkout main
$ git merge issue-9
```

### Helpful links 
| Issue | Closed by |
| --- | --- |
| [Issue #9](https://github.com/saminarp/rwar/issues/9) | [7546901](https://github.com/saminarp/rwar/commit/7546901318aecfaa12dea0ec638f88e6d5285bb0)
| [Issue #10](https://github.com/saminarp/rwar/issues/10) | [9eae23b](https://github.com/saminarp/rwar/commit/9eae23b97d40f4e1efc72d54cb1f49a03753cceb) |

## 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.