Git and Branched Development

John Souza
4 min readDec 7, 2020

Explaining the need for git, how to develop on a team using branches, and when to merge vs rebase

Git can be tricky for new developers. Someone who has never touched code can look at the very basic commands of “git pull origin main” or “git commit” and see only technical jargon. More complex issues can present more daunting challenges. For example, developers may have trouble navigating git branches or deciphering merge conflicts.

Git is one of the most powerful tools developers have at their disposal. A proper knowledge of git can save a developer hours of time on a project, or maybe even save the codebase itself! Git can perform, among other things, three operations. It can save your code, branch your code, and merge your code.

Git saves your code!

At its core, git is an open source version control software originally developed by Linus Torvalds, the creator of the Linux operating system.

To say it is a version control software is to say that it manages different versions of your codebase. Imagine you were writing a paper, maybe for school, maybe for a professional report, maybe for personal use. Let’s say you finished writing a first draft of that paper, and went on to a second draft. It would be a wise decision to save that first draft, copy the file, and start your second draft in that new file. Going through the rewriting process, we might end up deleting a few paragraphs that we deem unnecessary. If, when we edit the paper again, we realize that we actually do need those deleted paragraphs, we can go back to the original first draft and pull them out.

This process of saving different versions of your project is what git does with our code. Git manages the line by line differences between each “commit” of our code, and stores those differences in a history that we can go back to. We can even save those versions online and share them with others through websites like Github and Bitbucket.

Git branches your code!

Developers generally work in teams. Often, you’ll have more than one developer working on the same project or even the same file at one time. Git offers a tool called a “branch” to allow developers to keep their work clean from conflicts. By default, git projects start with a “main” branch (formerly known as a “master” branch). If a developer wants to work on the code base, it is a best practice to switch to a new branch, named accordingly with the feature being created, to work that specific feature. You create a new branch with the “git checkout -b <branch-name>” command, and you can switch to a previously created branch with the “git checkout <branch-name>” command.

This is helpful for two reasons. First, if two developers worked on the same branch, they would constantly have to deal with merge conflicts between their code. This opens the door to headaches and broken code. Second, the history of those git commits can stay very clean, because the commits will follow a logical order of each feature being created.

Git merges your code!

When you are done writing that specific feature, you can merge your code into the current development branch. Merging code takes the feature branch’s code and places it on top of the development branch’s code. Git will display the possible conflicts between the code bases, and you can sort through those conflicts with a text editor like VSCode.

As a developer, you may be caught in a situation where you are working on a feature branch, but someone creates functionality that you want to use for your project. You can also use merging here. However, there is a better tool at our disposal for these situations. You can also rebase your code. Rebasing is similar to merging in that it combines the code bases you have been working on. However, it differs from merging in that it does not attempt to combine the code at the point of the current commit. Instead, it takes the base of code that both versions share and changes it there. Rebasing makes your git history simpler and more navigable, as you do not have a new commit each time you rebase, and your merge is recorded at the beginning of your commit string, not at the end.

As a general rule of thumb, merging should be used when moving code from a feature branch into the development branch, and rebasing should be used when moving development branch code into a feature branch.

Conclusion

Git can be intimidating, but it is incredibly helpful for developers to manage their code. Between saving a history of your code that can be accessed at any time, offering branches that developers can create to write code simultaneously, and handling merges between your branches, git offers the developer one of their most powerful and cherished tools.

Relevant Links

Git Merging vs Rebasing: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

--

--