An essential skill in your evolution to become a Software Developer is learning to work with others. There are a number of ways to go about that, but one such way is working through Github. On paper Github isn't a very complicated thing, but when other people get involved, you end up tossing and turning in a web that sometimes feels hopeless. It never truly is though, and learning to work through that has really helped me out. Over the last week, I was tasked with creating a project with a group, which of course means sharing our progress through Github. This little blog of mine is just about some of the triumphs and failures of that process.
As far as cloning code from a repository goes, it's super simple. Github has a great UI that is relatively easy to understand. If someone has code and it's uploaded to the site, all it takes is a quick 2 clicks and you can have the code open in your own terminal. Adding collaborators is easy too, you just need to go into your settings. I think the main confusion comes into play when you incorporate branches. A branch is essentially just your own little split from the main code, which is useful so that you aren't messing with other people's work as you do your own. It's a neat way of doing things where at the end of every task, you can merge your branch with the main one and move on to create another branch. Sounds simple enough right? Well... it's a little bit harder than that.
Lets say that me and a friend are working on the same project, and we both share a file called "Home". Lets also say that the two of us were working on this project for a couple of days, and both made very minor adjustments to "Home" that were necessary to getting the app running. Even though we both believe we only made minor changes that shouldn't create a big ruckus, when we both go to merge our branches with "main", we encounter the issue of conflicts. Scenarios may exist where there are mutually exclusive lines of code, and both of them are relatively important to what we had been working on. Of course, after working on something for two days, neither person wants to give up on what they made. This is where communication is extremely necessary and illustrating to your partners what changes you plan on making.
In my project, we had to incorporate a search feature for the website that was very important to our overall vision. After I had finished my first few goals, I went on to try and work on that search feature. I ended up spending an entire day on it, simply because I couldn't understand how to implement it into our already-existing code. I knew I had a general understanding of how to do it from scratch, but it's entirely different when you're working with unfamiliar code and you don't know where to begin. You need to find the id's that you're trying to filter through, find the forms you need to add your html into, etc. But when you see a giant maze of ids and forms, it can get a bit daunting.
The real tough part is that even after you finish implementing everything, you need to merge your branch with the main one. There were a few times where I would go to merge my changes, and I'd get multiple error messages saying I'm behind on code so if I push my changes I'll be overriding my partner's work. In that scenario you need to end up pulling their code before merging yours, but sometimes their code that you just pulled could have an error in it and now you have to troubleshoot a problem that you don't know is even yours. Sometimes the problem lies in this gray area, a no-man's-land, where no one entirely knows why an issue is happening or whose code is conflicting with whose, but you have to work it out.
Luckily for me, my project was very well defined from the get-go, and my partners and I always discusses the changes we would make before we made them. This was in large-part to avoid the eventual issue of overlapping code. I would also like to mention how important the implementation of a wireframe is, in the early stages of web development. Having a base model to look at and understand prior to starting any code has been extremely successful in my experience.
This is all to say that even though Github can be challening to work through, it is a very essential and well-designed site that is equally as rewarding as it is tough. The experience of working on my latest project has helped me understand Github more, and I'm grateful for that. Next time around, I'll definitely try to be the leader in that regard, and try to help others work through the tough parts. I think it's great how much I feel like I'm learning and gaining experience. To that end, I guess I have to thank Github.