Getting started with Git

Pawel Nolbert

You have a project you want to share with other developers, or you want to start something with more people and need to share the code in a fast and reasonable way, for that you have you have version control systems like CVS, SVN, Mercurial and Git (there are other, this one are probably the most widely known).

We will be focusing on git which is widely known and used and it allows us to have remote versioning of our files as well as local versioning.

One of the advantages of local versioning is that it allows you to have the same file in different states by just having it in different branches, that way you can see the impact of a change locally or sent it in different branches easily for others in your project to test without having to juggle around with commented code.

TL;DR For those who prefer to learn by watching and just want to skip the theory, there is an example and references at the end of the article

Setting up

It doesn’t get simpler than this.

• Download and install this
• Open terminal and type “git”

Jargon

Some of the terminology used when using git:

• Branch — When you are using git your project folder becomes a branch, like a tree, there is the trunk (which is usually what’s in production right now that we call the master branch) and each feature being the branches;
• Conflict — When a merge between two branches is made and files have lines that cannot be merged automatically it generates a conflict that most be corrected manually;
• Merge/Pull request — When you finish a feature or solve a bug in a branch for it to be approved into the master branch is common to ask for another team member to validate the code and functionality;
• Fetch — When you want to update the local references with the remote repository, say someone created a branch and added it remotely, for you to be able to checkout you have to first fetch the reference;
• Pull — When you are already in a branch and want to update the files that were sent remotely by a team member into your local copy of that branch;
• Commit — A bunch of files you want to eventually send to the repository are stored as commits in your local branch;
• Push — When you want to send your batch of commits to the server you have to push them to it with git push;
• Stash — Files that you didn’t commit but where saving for later are stored in a local stash with git stash command;

File status

When working with git there are various status that your files can have, those being:

Untracked — A file that was never versioned by git. You can stage it for a commit using git add [file] or git add . to add all the untracked and modified files;

Tracked — Files that are being tracked by git, when a change happen you will see it in git status has modified;

Modified — When a versioned file is changed;

Staged —When you add a file or files to be committed with the same commit message. This usually happens after a git add command.

Committed — When you commit something it means it is ready to be sent to your remote repository, files that are in this state can be listed with git log (it will also show the rest of the commit history of the repository)

Remote — To send something to your remote repository you have to do git push else anybody else working on your project won’t see your changes, up until the “committed” point all the files are on your machine only.

Ignoring .DS_STORE file, .vsCode folder and node_modules

You can ignore files so that they do not show in your git by just creating a file named .gitignore , anything you want to ignore just add a new line to this file with the name of the folder or file.

Note that git won’t track empty folders. For that create a .gitkeep or another empty file in the folder you want to commit

Repositories

To save your work remotely so that things don’t remain on your machine you should use an online repository:

• Github — Probably the most famous of them all, you can have as many public repos as you want, for private ones you have to pay monthly;
• Bitbucket — Upwards to five users you can have as many private repos as you like.

If you prefer to install it on a server of yours you can download and install Gitlab.

Git flow

To organize the way work is done using git we tend to separate each little feature by creating a branch instead of everyone working on the same master/developer branch.

By the end of that feature we request a merge to the master/developer branch.

An utility to help you follow a git workflow is gitflow, install it and to initialise a flow on your repo just run git flow init .

With a repository initialised this way this utility works has a shortcut to creating branches for features, bug fixes and releases.

A normal process would be:

git flow feature start [name] — this will create a feature branch with the name of your feature. It would be the same as for example git checkout -b feature/[name] master

git flow feature publish [name] —Send to the remote your current feature so that you can save it outside your computer, share it with the rest of the team developing and to be able to create pull requests.

Another way to organize your repository is by setting a branching model culture like this one here.

Git porcelain

Git has commands that deal with the core of its system used for scripts for instance, those are called the plumbing commands. On the other hand, the ones that most people use on a daily basis and are usually more than enough to get the job done are called the porcelain commands.

Some of this commands were already referenced previously, a basic ideia of what each of them do:

• git add — Set the state of a file from untracked or modified to staged
• git commit — Grab the current staged files and create a log describing the change made in those files. To add a commit message in a single command just do git commit -m “[message]”. You can open notepad instead of vim by setting the commit message editor like this:

git config --global core.editor "[path to editor]"

This way the next time you use git commit it will open the editor for you to set the message, when closed it will finish the commit.

• git push — Sends everything you committed to the server remotely;
• git fetch — Fetches references of branches remotely;
• git pull — Get new commits for current branch that are available remotely;
• git checkout — Get the branch from the remote server;
• git reset — Revert a commit you did by mistake (don’t confuse with git revert which will create a new commit message saying you reverted the change).

You can easily see a list of both porcelain and plumbing commands in a great answer on stack overflow here.

Tools

If you don’t like the terminal approach and prefer having a GUI there some very cool tools to help you visualize your working process:

• Source tree (free)
• Github desktop (free)
• Git Tower (paid)
• Git Kraken (paid)

Github example

“Theory theory theory, what about a real example!!!” — I feel you, you want to see this being applied to have a better grasp of what git is, I will be using git but any other repository will have the same flow. I will be using the command line for this, you can also use the tools stated before if you prefer.

Create a github account

First and foremost the obvious, create an account on github and create a repository by pressing the “+” in the upper right corner near your image

You can initialise with a README, .gitignore and repository licence if you want those from the start

Having a project from the get go

After the repository is created it will give you a set of instructions of how to clone it to your local machine or have a current local project pointing to this newly created repository. Let’s say we already have some files to commit:

Our folder has two files we want to send to the repository, set this folder as git ready with git init then add the remote

git remote add origin https://github.com/daspinola/sample-article.git

Create a commit with your files

git add . && git commit -m "Initial commit"

And then send the files to the remote with

git push -u origin master

And when you update the github project page you will se your files there

Having new changes remotely

To create a local branch we simple run the command git checkout -b [name] (git branch followed by checkout would also work, this is just a shortcut)

Updating local references

I changed my index.htm file to now use the JS file and I want to have that change mirrored in the remote. For that I git add index.htm followed by my commit message with git commit -m “Include js file” , i refresh my remote and….nothing? Yes, because we have yet to send this new branch to the remote repository, git add and git commit are commands only to our local project branch, to send the changes to the remote simply do git push. if it’s the first time pushing for changes it will ask you for the upstream which in what remote reference you want your files to go, just go with the suggestion

git push --set-upstream origin feature/include-js

You will now have your branch in the remote repository.

Note: You can have as many commits as you like before pushing to the remote.

Pull request

“My changes are not in the master!” — Well my friend, you’ve done your changes in the branch called “feature/include-js” that is why you don’t see the changes in the master, for that we usually do a pull request, which is to ask for someone else to review our code and functionality before it is sent to the master which we can see as our “production ready” branch, we don’t want bugs on that one do we?

To do a pull request, in the branch page (image above) just select “pull request” (“You don’t say sherlock”).

The reviewer and assignee are usually other person that not yourself but I was doing this alone so I sent to myself. #foreverAlone

After it was sent it will show on the pull request tab

When accepted you will see a merge with the master, when watching the logs and files everything should be updated

“I want a collegue to work on this with me”

Just have him install git and clone your repository with the command git clone [repo] were [repo] is the link of your project

Project link

This should give you an ideia an a base to get you started, everything in this process can and should be refined as you learn more about the topic, you can start in the next topic on how to get to more more about git.

More learning material

To get a more visual approach of an introduction of git and github you can watch Kent C. Dodds course on egghead here.

You should also read the git book that can be found here.

For an interactive alternative you have git branching by Peter Cottle.

Article 8 of 30, part of a project for publishing an article at least once a week, from idle thoughts to tutorials. Leave a comment, follow me on Diogo Spínola and then go back to your brilliant project!