Using Git while working with a team versus using Git while working by yourself are similar tools, but different in certain ways. While starting my job, two key differences in using Git are

1. Branching: Using branches to control your own code, and then pushing that branch to the source branch

2. Pull Requests (PR): Code reviews from other developers on the team to ensure that the code will not break anything, the code will not cause a merge conflict, and the code is clean and tiny (among other things).

But we're getting ahead of ourselves. The past two days brought me to a Git tutorial, and so I'd like to speak on it.

Git Basics

Git is a source control tool to help with work flow. It's also great to use for collaborating with fellow developers so everyone isn't stepping on everyone else's toes. Source control tracks and manages changes in code, which includes the current version of the project. Branching and code review are collaborative tools that help teams work together to achieve clean, working code.

I will talk about Git in terms of basic servers resources such as GitHub or Bitbucket. These tools allow developers to easily create and manipulate their own branches on the source code. It also displays team projects visually, because in terms of Git, source code can live in servers. Tools like GitHub and Bitbucket use those servers to display the source code and users working on the project.

Essentially, there are two versions of the code in Git - the remote server, typically referred to as 'origin' and the main branch 'main' (in the past, master) and the local on a developer's machine. The local branch starts as 'main' as well, but it is not prefixed with origin. When a developer first builds a project, the head of the server branch (origin/main) points to the local branch (main).

When a developer clones from the origin/main branch, their local branch main is branched from origin/main. If there are changes to origin on the local machine, and those changes are staged (more on that later), then origin/main is said to be behind the main branch because those code changes are invisible to the server code. It is not until the code is pushed to origin/main when the server code is caught up with the local code. This can be tracked with a status check.

Git Commands

It's probably easier to follow all of this with an example while using the git commands. The easier version of creating a project is through a website like GitHub and Bitbucket. There, the developer can create a project and a repository by following prompts. It will also explain how to get the code from the repo onto the developer's machine. Retrieving that code is called cloning.

$ git clone <https://www.github.com/path/to/sourcecode.git>

This is the command used on your terminal to clone the git repository onto the developer's local machine. Again, this will result in the origin/main branch on the server to point to the main branch on the developer's local machine. Once cloned onto the developer's machine, the developer and write code to their heart's desire!

After changing code and satisfied with the results, the developer will want to stash the code changes on his local repository main. Stashing the code changes will essentially save the code on the repo and, just in case anything were to happen to the repo, the developer can easily get the code changes back from the commit. There are two steps to stashing code.

$ git add <filenames>

The add command will first add the changes into the stash. Developers may also add all files in the directory by putting a period (.) in its place.

$ git commit -m "Add a descriptive message about the code changes committed"

Once the changes have been added, they can be committed, which will permanently place these changes onto the local branch. Commits will have their own ID for the developer to reference.

$ git status

The status command will check the changes in the developer's local repo versus the remote repo. The most obvious times that status can be useful

• Status will let the developer know what branch they are working on,

• When the developer makes changes in the code, but did not add or commit those changes to the local repo, status will let the developer know what files have been added and changed, and let them know that they have not been added to the stash,

• Between adding and committing the code to the local repo stash, it will show the code changes in green, but it will let the developer know that it has yet to be committed,

• After committing code changes to the local repo, status will let the developer know that they are working ahead of the remote repo origin/main by x number of commits

$ git push origin main

To merge the code changes from the local branch main to the remote branch origin/main, the developer will need the push command. This command will push all the stashed code into the remote server where it will then live.

$ git fetch

$ git merge

$ git pull

Other developers that have branches from origin/main will then be behind origin/main and will need to fetch the code from the source code, and merge that code into their own. The fetch command will stash the origin/main changes for the developer to look over before merging the changes into their own local branch. The pull command will automatically merge the changes, which may cause a conflict.

$ git branch <branch name>

$ git checkout <branch name>

$ git checkout -b <branch name>

$ git fetch && git checkout <branch name>

The final piece of the puzzle is for the developer to create their own branch to work on. A branch starts as a single commit, and the follow commits build upon that branch head. A developer can move amongst the branch and manipulate code without the fear of ruining anyone else's code or the source repository.

As you can see, there are a number of ways to create branches. The first way is to create a branch and then maneuver to that branch in two different commands - branch, and then checkout that branch (where checkout is moving from one branch to another). The second way is to immediately checkout a branch that was just created with the -b flag.

By just using the branch command by itself, it will list the branches that have been created locally, and by using the -a flag, it will list all branches, local and remote. That last branch command, fetch and checkout, will be mentioned in the next section.

Code Review

The process above is for smaller teams, or for a single programmer who may want to just keep track of his code and not ruin their old source code. For larger teams or enterprise code, what I am now exposed to in the large company I work for, teams will use Pull Requests and code reviews to ensure correct code and cleanliness of code when a developer's branch is being merged into the remote code base.

That last branch creation where a developer will fetch and then checkout onto the branch is used when a developer creates a branch using Bitbucket or Github. The branch creation will be associated with the remote branch (and story, if your team is in a scrum format) that you want to base your branch off of. Then use the fetch && checkout command to get that branch from the remote repo to your local.

The difference between the above work flow and a team work flow is when a developer uses the $ git push command, the branch commits are pushed to the source code under that branch name. The developer then needs to create a Pull Request for other developers on the team to review the code that the developer changed on his branch. If the code passes the review, the developer can then merge the changes onto the main remote branch. However, if the developer's code does not pass code review, the developer needs to continue working on their branch in order to pass the tests required to get through the code review.

In Review

So many benefits to Git. Ya made a mistake, you can go back to the source code on your remote repo. You can revert back to that code. You can check the changes that you made. And that's just when you're working by yourself! You can review everyone else's code and see what changes have been made, where, when, and why!

Not only that, but there are a lot of other git commands at your disposal. I only brushed up on the main ones, but Git is so powerful and complex that there are cheatsheets and stackoverflow threads dedicated to this topic because of how confusing developers can get over simply deleting one commit.

Go out there and make mistakes. Get that code reviewed. Revert back to your old code. Have fun!