Category Archives: GitHub

Why Git

Why is it always git

Photo by RealToughCandy.com on Pexels.com

The version control system that every programmer uses. Even in my computer science class, we had lectures dedicated to Git, the commands in Git, how Git is used, what Git is used for, and just so much Git. The funny thing, is there are other version control systems such as Mercurial, but they aren’t ever brought up they are there but feel overshadowed by git. So the question I am asking now is why Git. So I did some investigating.

The question: what does Git do that is so special compared to other version control systems? Now version control systems can do all sorts of things such as allowing developers to see what has been changed, enable collaborative work, and branch and merge changes to a repo. If multiple can do this, then what does git do differently? An article from Geeks For Geeks lists several. Git can be worked on offline and is resilient because multiple developers can have copies of the repo, and any local repo can be used to restore a project. It also comes with conflict resolution that’s allows one to handle merge conflicts by providing tools to solve those problems. So what about the other systems. Well, GFG got that covered. Here are some comparisons.

Subversion

Compared to Git, the architecture is centralized, one single central repo

Fewer branching and merging options

Better performance

Mercurial

Smaller community compared to Git

Not as much flexibility as Git

Perforce

Can handle very large code base

Not as flexible as Git in terms of merging

Git is Open Source and Free, while Perforce isn’t

That is a decent amount of reasons to use Git over other VCS. I think the community part is important for such a popular system, because if you aren’t too familiar with the commands that come with Git, then you have a lot of people that can help. There are a lot of forums and articles about Git tools out there if you ever need it.

I also feel that the collaborative aspect of Git is, very helpful. A lot of projects have a lot of people working on them, so having something like Git that can handle it and make the task easier is great. Also, the fact that it is accessible helps with that too.

Git being so popular makes a lot of sense now, accessibility, community, and collaboration are what a lot of developers require, and I have to say Git provides that well.

GeeksforGeeks. (2024, September 19). Git vs. other version control systems: Why Git stands out? https://www.geeksforgeeks.org/git-vs-other-version-control-systems-why-git-stands-out/

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Workflow for a Developer


This week, I came across an post titled “Improving Developer Workflow” on Vercel’s blog, and it caught my attention because I’ve been trying to figure out how developers stay productive while coding. The article dives into different ways to make workflows more efficient, focusing on tools and practices that help developers ship better code faster. Since I’m new to computer science and still figuring out how to work effectively, this post felt super relevant to my learning journey.

The post highlights key aspects of improving developer workflows. It starts by discussing the importance of having fast feedback loops, meaning developers should quickly see the results of their code changes. This post introduces tools like Vercel’s platform, which makes it easy to preview, test, and deploy changes almost instantly. Another focus is on collaboration, emphasizing how tools like GitHub help teams share work and review code seamlessly. It wraps up by stressing the value of automation, like setting up CI/CD pipelines, to reduce repetitive tasks and ensure consistent quality in the codebase.

I chose this post because workflow optimization feels like an essential skill for any developer, even beginners. Sometimes I get stuck on repetitive tasks or wait too long to test my code changes, which can be frustrating. This post seemed like a good way to learn how experienced developers streamline their processes. Also, tools like GitHub and CI/CD were mentioned in class, so I wanted to understand them better.

The main thing I learned is how fast feedback loops can save a lot of time and frustration. For example, using tools like Vercel lets developers instantly preview their changes in a live environment, so they don’t have to guess if their code works. I also learned how CI/CD pipelines automate testing and deployment, which not only saves time but also reduces the risk of errors. I realized that these tools make a developer’s life easier, but they also require some setup and understanding, which I’m excited to learn more about. Another cool takeaway was how much collaboration matters in a developer’s workflow. I’ve used GitHub for simple projects, but the blog post made me realize how powerful it can be when teams use it for pull requests, code reviews, and tracking changes.

This blog post made me want to improve my own workflow by setting up faster feedback systems, even for small projects. I also plan to explore tools like GitHub Actions to try basic automation for testing. In the future, I hope to use these techniques to work more effectively on team projects and avoid common frustrations like repetitive tasks.

Resource:

https://vercel.com/blog/improving-developer-workflow

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Version Control

Source: https://www.spiceworks.com/tech/devops/articles/what-is-version-control/

This article is titled “What Is Version Control? Meaning, Tools, and Advantages.” The main purpose of version control is to “track the progress of code across development and iterations and also aids in managing changes during the life cycle.” Records are kept of all changes with names, timestamps, and other important information. So, the process by which software code is monitored and the way in which changes are made is called version control. A huge benefit of version control is being able to look at the revision history and determine where problems originated from, and who caused them to happen. This allows for increased efficiency regarding workflow considering that the time required to locate problems is greatly reduced. Another benefit of version control is branching. “Branching is a distinct approach to version control where development programs are duplicated for parallel versions of development while keeping the original and working on the branch or making separate modifications to each.” This allows for enhanced collaboration where development is increased, issues are resolved, and code remains organized. A couple very popular version control tools are Git and GitHub. The creator of Linux, Linus Torvalds, created Git. The memory footprint of Git isn’t vast and is able to follow changes in any files. It is a very simple version control system and as a result is used by top companies such as Google. GitHub is a service that enables development teams to collaborate and keep track of all their code changes in a cloud environment. GitHub is secure and reliable, and as a result is also widely used. Through the use of a version control system the following can be achieved: “streamline merging and branching, examination/experimentation with code, the ability to operate offline, creation of regular/automated backups, communication through open channels.” Overall version control aids in the maintenance of reliable code bases and enforces accountability for effective collaborative development. 

I selected this article because we are actively learning about version control in class right now so I figured it’d be the perfect time to read up on it more. Reading the GitKit chapters has exposed me to different git commands and GitHub usage. It was interesting to read in this article about all of the in-depth benefits that version control offers and clearly showcases why even top companies such as Google use it to optimize their workflow. In future practice, whether it be at a job or while working on an individual project, I will use version control to improve collaboration and the ease of maintenance of my code.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Tackling Merge Conflicts with GitKit: A Student’s Guide to Smoother Collaboration

Working on team projects in class has really brought out how tricky merge conflicts can be. Nothing quite like seeing “conflict” pop up after a pull request to slow things down! For this blog entry, I looked into a post called “Mastering Merge Conflicts with GitKit” , which breaks down why merge conflicts happen and shows how to tackle them using GitKit’s built-in tools. Since our course covers version control and team-based coding, I figured learning to manage these conflicts more effectively would make a big difference, not just now but for any future projects.

Summary of the Selected Resource

The post explains why merge conflicts occur in collaborative projects, like when multiple team members edit the same file or branch in different ways. The author points out that conflicts are actually pretty normal in team coding—it’s just part of working with a shared codebase. GitKit’s approach to handling conflicts was the real game-changer for me here. It uses interactive conflict markers, visual diffs, and a guided merge workflow to help developers see exactly where conflicts happen and resolve them without a lot of guesswork. It’s clear from the blog that these features simplify what’s often a frustrating process, making it more manageable and, honestly, less intimidating.

Why I Chose This Resource

I picked this post because merge conflicts have been a big obstacle for me and my project teammates. They always seem to come up at the worst times—right when you think you’re wrapping up! Learning more about practical strategies to handle them seemed like a solid move. Plus, I hadn’t really explored GitKit’s full range of features before, so this gave me a chance to see how it can streamline conflict resolution. With team coding becoming more common in projects, internships, and industry work, knowing about these tools feels pretty essential.

My Takeaways and Reflection

Before reading this, I mostly just knew the basics of handling conflicts through the command line. But after seeing what GitKit offers, I realized how helpful visual tools and conflict markers can be. They make it so much easier to understand what’s causing the conflict and to feel more confident about fixing it. Having a clearer view of what’s happening in the code feels like it will help me avoid mistakes and keep our project moving forward without so much stress.

Looking ahead, I’m definitely going to use these GitKit techniques in my future work. I plan to keep practicing conflict resolution so it becomes second nature and doesn’t disrupt my flow as much. I can see how this will really come in handy, especially when I start working on larger projects or in a professional setting where team collaboration is essential.

Link to the Resource

https://dev.to/htsagara/handling-merge-conflicts-in-git-how-to-fix-and-prevent-them-1m62

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Week 14 – Blog for both CS-343 AND CS-348

So for this blog, I wanted to find a topic that is applicable to both classes, so I wanted to look more into GitHub and the ways it functions compared to GitLab.

I duplicated by Secret Santa Generator repository from GitLab: https://gitlab.com/worcester/cs/cs-348-01-02-fall-2023/students/bpoole/secret-santa-generator and duplicated it in GitHub here: https://github.com/TempuraShrimple/Secret-Santa-Generator

To do this, I had to open up the local repo on my PC, create a new blank repository on GitHub, and run the following commands:

Once this was done, my repository was transferred over to GitHub successfully, without harming my GitLab repository in any way shape or form. Everything, including the history of the repository, was included with this transfer, which I think is really cool.

One difference I immediately noticed between GitHub and GitLab is that GitHub allows you to add a short description on the right-hand side of the repository, allowing a quick way to figure out what the program intends to do without having to look at the README.md. Obviously if you want more information, the README.md is very important in that case.

Both sites have a really good planning structure, with GitLabs’ issue boards, and GitHub’s project tab, which is structured very similar, but I think GitHub’s might be better as it allows you to choose from a lot of different templates like Kanban, Team retrospectives, and bug tracking, which I think is really cool. You’re also able to customize it as you please, so you’re able to set up a scrum structure like we did in GitLab for many of our projects. However, after looking into it, if you want to utilize Scrum, it seems GitLab is definitely structured better with preset pillars that are made with Scrum in mind. However, it’s a toss up on which would be better to utilize in this case for project management, in my own humble opinion.

GitLab also has some advantages in the construction and development aspects of this comparison, as after looking into it, GitLab is able to automate releases and builds of code once they are ready to be done so, and GitHub doesn’t have this capability at all.

https://about.gitlab.com/competition/github/?stage=Configure

This seems extremely useful for a program that has set deadlines and not enough time to do these things during, say, a Sprint. It allows a lot more flexibility with the work being done in a repo and can allow a lot more efficiency and productivity. I will definitely look into this more later on when I start using this repo I cloned myself.

All in all, after looking things over, it seems like GitLab has a lot of additions that make it better over GitHub in all sorts of ways, and I’m surprised GitHub is used more than it. I should probably introduce my friend I’m working with on GitHub for his game engine for this if he ever develops a much bigger team, as many of the planning-oriented inclusions GitLab has would be extremely beneficial!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Setting up your development environment

This is a guide for creating a new Android Eclipse project from source code on GitHub. It is tailored to my independent study project for the benefit of my partners, but it could be easily adapted to any Android project.

Note: This guide was created for Windows 7 64-bit. Other versions of Windows should be similar.

1. Download and install Java SE Development Kit for Windows x86

Note: I highly recommend NOT installing to the default C:\Program Files (x86)\Java\ folder. The Program Files folder has very restrictive permissions which may cause file writing/copying errors in the future. I chose to install to C:\Java\.

2. Download and install Android SDK for Windows

Note: Again I recommend NOT installing to the default folder. I chose to install to C:\Android\.

3. Run the Android SDK Manager and install the groups: Tools, Android 4.1 (API 16), and Android 2.2 (API 8).

4. Download either Eclipse Classic for Windows 32-bit or Eclipse for Java Developers for Windows 32-bit

5. Extract the downloaded eclipse\ folder into your Java\jdk*\ folder

6. Download and install GitHub for Windows

7. Run Eclipse, and choose your GitHub folder as your workspace

8. Install Eclipse ADT Plugin

Note: If you get an error after restarting Eclipse about not being able to find the Android SDK, just click the Preferences button and point to your Android\android-sdk\ folder.

9. Create a new Android project, and then close Eclipse afterwards

Name the project Task Butler, and name the package edu.worcester.cs499summer2012. The target SDK should be API 16 and the minimum required SDK should be API 8.

10. Clone the CS499Summer2012 repo to your local GitHub folder

11. Move the local repo files into your Task Butler folder

  • In your GitHub\Task Butler\ folder, delete everything EXCEPT .settings\, .project, and .classpath
  • Move everything from GitHub\CS499Summer2012\ into GitHub\Task Butler\
  • Note: Make sure “Show hidden files, folders, and drives” is enabled in Windows Explorer’s Folder options so you can see the hidden .git folder
  • Delete the now-empty \GitHub\CS499Summer2012\ folder

12. Reopen Eclipse, and the project should now have all of its files (and lots of errors!)

13. Download ActionBarSherlock and extract it somewhere

I chose C:\Android\

14. In Eclipse, import the library\ folder inside the ActionBarSherlock folder as a new project

15. Modify the library’s Android properties and Java Compiler properties to get rid of errors

Make sure the build target is set to 4.1 and the “Is library” checkbox is checked.

Make sure the Compiler compliance level is set to 1.6.

16. Modify Task Butler’s Android properties to include the new library

Make sure the build target is 4.1 and add ActionBarSherlock to Library (if there is one listed already with a question mark, remove it).

17. If necessary, clean the project and it should rebuild itself with no errors.

The project is now ready to be worked on!

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Code is live on Github

Now that the app is in development, our work is live on Github. Check it out by clicking the Github link at the top of my blog.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

The trickiness of using Git in an Eclipse project workspace

I know there is a Git plugin for Eclipse, but I prefer to do things the old school way with terminal commands. So when it came time to make sure my Eclipse project folder was being tracked by our remote repository on Github, I thought I could just clone our repository and then create a new Eclipse project in that same directory. Except Eclipse does not let you create a new project in a directory that already exists. And I wasn’t going to try to clone into a directory after it had already been populated by local Eclipse files; who knows what kind of problems that would have created.

If there is an elegant solution to this problem, I didn’t find it. I changed the name of the cloned directory, then created my Eclipse project using the original directory name now that it was unused and available. Then I moved all the Git files into the new directory, and deleted the now-empty one with the changed name. And everything works great.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Using Git in Windows

With our GitHub repository ready, and now that my Android development environment has been setup, it was time to install Git so I can actually start working. Git is a Linux tool and all my previous Git experience has only been inside that environment. But luckily Git has been ported to Windows, so I can use Git on my Windows machine without having to run it inside a VM. There are several options for running Git in Windows, and first I chose msysgit, the official Git for Windows project. I then abandoned that in favor of the GitHub application, which promised seamless connection to the GitHub website, including automatic maintenance of SSH keys.

The GitHub app has a nice GUI interface, and seems to be very easy to use. But I honestly haven’t used it much–the app also installs a Git shell, which I vastly prefer to the GUI. The Git shell emulates a Linux terminal, inside a Windows command prompt. Several of Linux commands are emulated inside the shell, such as cp, mv, rm, ls, cd, and others. Tab completion is also implemented which is wonderful. The emulated commands are not as powerful as their real versions (for example, typing “ls” works, but my preferred “ls -lh” doesn’t), but it’s still great to have this option. You can even open text files for editing from within the command prompt– just type notepad instead of nano or gedit. Lastly, a hugely useful addition to this Windows implementation that isn’t even in the Linux original:  the prompt in the shell uses symbols to help you keep track of your added, modified, and removed files, and changes color depending on your commit status!

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Organizing our GitHub repository

Our Android project will have an online repository hosted at GitHub. I’ve never used GitHub, though at work I use a local install of the similar Gitorious service. So far, we don’t have anything in the repo besides a GPL notice. The repository does have an integrated wiki that I have put some work into already. James and I discussed how to organize the repo and we decided we wanted to follow a professional approach that an actual project team working on commercial software might follow. Here is an excellent description of the model we will be using.

Basically, there will be four permanent branches. The first two branches, jon-dev and james-dev, are personal development branches that will hold snapshots of the project as we are working on it. We will keep our individual work separate in these branches so nothing one person does can affect the other. Here we also have the freedom to absolutely break the app while not affecting the snapshots in the next two branches. The code in these branches cannot be guaranteed to  build into a perfect working app, but that is to be expected because this is the entry point for brand new contributions.

The third branch, develop, is where James and I will merge our work from our individual branches after we have gotten our code working the way we want. Snapshots in the develop branch should build into a relatively stable app, similar to nightly builds in a major open source project, though bugs may still be present.

The fourth and final permanent branch, master, is reserved for major releases of the app. Once the code in the develop branch has enough features implemented, and has been tested thoroughly, it can be merged into the master branch and tagged as a milestone build. Apps build from code in the master branch should be considered stable and without major bugs.

We can also create temporary hotfix branches as we need to. For example, if a bug is discovered in the master branch, we can create a branch to fix the bug, merge it back into master after the fix has been tested, and then delete the temporary branch.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.