Why Git?


From web developers to application developers, Git is useful to anyone who writes code or tracks changes to files. So, what is Git all about and why should you start using it for creating plugins or maintaining files for QSC Communities?

What is Git? 

Git is the most used version control system. It tracks any changes you make to files. The immediate benefits are that you can keep a log of what has been done, as well as revert to earlier versions if needed. Git also makes collaboration easier by allowing changes made by multiple people to all be merged into one source, making it ideal for collaborating with code, or any other file formats. Regardless of whether you are writing code by yourself or working as part of a team, Git is useful for development projects. 



Git is software that runs locally. Your files and their history are stored on your computer. You can also use online hosts (such as GitHub or Bitbucket) to store a copy of the files and their revision history. Having a centrally located place where you can upload your changes and download changes from others, enables you to collaborate more easily with other developers. Git can automatically merge the changes, so two people can even work on different parts of the same file and later merge those changes without losing each other’s work! 

Ways to Use Git 

Git is software that you can access via: 

  • A command line Interface (CLI), also called terminal  
  • A desktop application that has a GUI (graphical user interface) such as Sourcetree shown below, or using the GitHub desktop application. For more on how to use it with BitBucket, read this article from Kevin on how to share files using SourceTree. 


  • An extension for your code editor. By example, VS Code has extensions to push your local files to the cloud. Check these setup guides for BitBucket and GitHub


Git Repositories 

A Git repository (or repo for short) contains all of the project files and the entire revision history. You can take an ordinary folder of files (such as a website’s root folder) and tell Git to make it a repository. This creates a .git subfolder, which contains all of the Git metadata for tracking changes. 

Stage & Commit Files 

Think of Git as keeping a list of changes to files. So how do we tell Git to record our changes? Each recorded change to a file or set of files is called a commit. 

Before we make a commit, we must tell Git what files we want to commit. This is called staging and uses the add command in the terminal. Why must we do this? Why can’t we just commit the file directly? Let’s say you’re working on a two files project, but only one of them is ready to commit. You don’t want to be forced to commit both files, just the one that’s ready. That’s where Git’s add command comes in. We add files to a staging area, and then we commit the files that have been staged. 

Remote Repositories (on GitHub & Bitbucket) 

Storing a copy of your Git repo with an online host (such as GitHub or Bitbucket) gives you a centrally located place where you can upload your changes and download changes from others, letting you collaborate more easily with other developers. After you have a remote repository set up, you upload (push) your files and revision history to it. After someone else makes changes to a remote repo, you can download (pull) their changes into your local repo.



Branching, Forking & Merging 

Git lets you branch out from the original code base. This lets you more easily work with other developers and gives you a lot of flexibility in your workflow. 

Here’s an example of how Git branches are useful. Let’s say you need to work on a new feature for a website. You create a new branch and start working. You haven’t finished your new feature, but you get a request to make a rush change that needs to go live on the site today. You switch back to the master branch, make the change, and push it live. Then you can switch back to your new feature branch and finish your work. When you’re done, you merge the new feature branch into the master branch and both the new feature and rush change are kept! 

When you merge two branches (or merge a local and remote branch) you can sometimes get a conflict. For example, you and another developer unknowingly both work on the same part of a file. The other developer pushes their changes to the remote repo. When you then pull them to your local repo, you’ll get a merge conflict. Luckily Git has a way to handle conflicts, so you can see both sets of changes and decide which you want to keep. When merging a branch, git only has to run a differential on the work that was changed. 

Forking is more expensive. When merging a fork, git effectively has to differentiate both codebases against one another, as a fork represents two full copies of the codebase. Forking creates a full copy of your repository, whereas branching only adds a branch to your exiting tree.  
 
If file size is not a concern, we encourage users to use the forking process for when contributing to someone else’s code repository. 

Pull Requests 

Pull requests are a way to discuss changes before merging them into your codebase. Let’s say you’re managing a project. A developer makes changes on a new branch or decides to fork the repository and would like to merge that branch/fork into the master. They can create a pull request to notify you to review their code. You can discuss the changes and decide if you want to merge it or not. 



Learn more about Git 

We hope this has clarified what Git is and how it can improve your workflow. You can learn more about Git and how to use it for developing with Q-SYS. 


Here a few references to help you get started: