What is git?

The Problem with Collaborative Work

Imagine that you and your classmates are working on a group essay for a school project. While working together, you have created several working versions of the document and are not sure how it will all blend together. At the end, you make a final copy of the document out of all of the working versions of your document to bring to your colleagues.

When everyone comes together, they each have a final version of their own document. Now, they have to merge that together into a final product for submission. This is what the git process is like: making changes to a document or a file over time, and all of those changes get merged into one final project, which is the entire application.

What Does Git Mean?

Using git, files are held in repositories. You can think of a repository as a folder/bucket where all your files live. Git is a version control system. This means that when changes are made, they are written to a repository, which allows users to easily keep track of the changes that have been made. In addition, users can see the history of the changes by going back to a previous version (commit) of that file itself. Common platforms that people use include GitHub, GitLab, and Bitbucket.

Centralized vs. Distributed

In a centralized system, there is a remote repository with the files living on one computer. Users interact with the remote repository directly, and the repository is centralized. Many people can work on the repository at the same time, but issues may arise if two users work on the same content at the same time.

When using a centralized system, there is one remote repository that developers interact with directly

In a distributed system, there is a remote repository but each person on the team has a local repository which is a version of the remote repository. When changes are made to the local repository, these changes can be pushed to the remote repository.

Branching is the process of pulling the files from the remote repository to the local computer. This is done to work on a specific feature or features. When a branch is created, that feature can then be edited and copied, with each branch being a different version of that feature.

When using a distributed system, developers access local repositories in addition to the remote repository

Common Git Commands

Git init: Turns a folder on your computer into a repository
Git clone <url>: Creates a local repository on computer from an existing remote repository
Git add: Adds a file in preparation for committing & pushing to a remote repository
Git commit: Takes a snapshot of the files that have been added and saves them as a state that can be reverted to
Git push: Pushes branch to the remote repository
Git stash: Takes changes that have been made and saves them remotely so they can later be retrieved, if needed
Git stash pop: Retrieves the latest stash object and restores the file changes that have been made
Git pull <remote><branch>: Gets the most recent work from the remote branch onto your local repository
Git branch: Lists all of the branches that are available
Git checkout (with a specific branch name): Switches to a branch to see the work that is being done on that branch, or can be used to create a new branch

Common git commands listed above

The Dev Lifecycle

Typically, the Dev lifecycle begins with local repositories, where team members work on different features. Once each developer is done with their features, they can push them to the remote repository so that others can view their work.

Imagine that there is a developer that wants to push their work to the remote repository. Another developer on the team, a product manager, or a product designer may want to view their work first, before merging their code into the production code and showing it to end users. This is where preview environments would help the team.

Preview Environments Using webapp.io

In this example, there is a developer that is working on a feature. The changes to the feature are pushed to the remote repository. Using webapp.io, the changes that are made are picked up and a preview environment is created to display the changes made to the application. This preview environment has its own unique URL that can be shared with other developers, product managers, product designers, or any stakeholders that are involved in the product development process, regardless of if they are technical or non-technical. Learn how to set up production ready preview environments for your React application.

Why Learn webapp.io?

Testing code becomes easier

Can share preview environments with external stakeholders or non-technical stakeholders easily
Easy to implement initially and can grow alongside a project
Can use to level up at work (get promoted without breaking things)