An introduction to git

9 min readFeb 10, 2023

Git is fundamental for software development but it can be very daunting for new developers. With this article, I try to clarify some concepts and show the most used commands in my daily work, to give starting point with git and take off the burden of anybody that is trying to learn it. Let’s start with some basic definitions that will help you understand more about git.

Git is a version control software that lets you track the progress of a project by keeping track of all the changes made to it. It’s widely used in the industry to manage projects and in conjunction with cloud repository systems like git-hub, git-lab, or bit-bucket you can access your code anywhere.

Git uses a command line to do its operations. On Linux systems, the command line is the same as the terminal and just using the “git” instruction is enough. On Windows, there are several ways to access it. The first one is the git bash program that is installed by the manager when you install git. The second is either through the cmd (command prompt) or the windows terminal (from the windows store). The windows terminal and the git bash use “Linux-like” commands (pwd, cd, clear,….), and the cmd uses its own set of commands, so it is recommended to use either the terminal or the git bash when in Windows.

Git uses a local file called a repository to keep track of the changes made to the project and all its files, this repository lives inside the .git folder(the dot indicates that is hidden). You can select which files will be tracked by git using a .gitignore file, this file is a hidden file, so if you are using windows and want to edit it you will have to set your viewing settings for the folders to “show all”. Inside this file, you put the relative path to the file or folder you don’t want to include in the repository, and git won’t track them. All the other files that are not included in the gitignore file are tracked by git for the repository changes, this means that any change that you make to the file can be viewed in detail comparing it to the latest committed version of it. New files are marked as untracked and will require a commit to the repository to start keeping track of the changes. You can also revert to any previously committed version of the files in the repository and this is why git is so useful, if you make a mistake you can go back to any previous version when it was stable allowing for quick experimentation, if the changes you applied work you commit them to the repository, if not you go back a previous state.

To get access to all the potential of git you have to create a repository inside the root folder of your project. To do this you just have to run the git init command in your terminal inside the correct folder, this command will ask for some basic information and then the .git folder will be a part of your project folder. If you are using an IDE with git integration like VSCode you can start seeing that the filenames change color and have letters next to them to indicate their status. VSCode uses U and green highlighting for new untracked files, M and pale yellow for tracked files that have been changed, and A or staged files with their corresponding color for indicating if they are being tracked or not. If your IDE doesn’t have git integration you can check the status of the files using the command git status or downloading an additional application to manage your repository from there, like Git SCM client or Git Kraken.

Now that we talked about local repositories now we are going to dig into cloud-based repositories. There are many remote repository hosting sites like BitBucket and GitLab, but by far the most popular one is GitHub, each one offers different functionalities and has workflows that will help you achieve what you need, so do some research before choosing a remote repository provider for your project. Let’s focus on GitHub, you have to create an account and a profile to access GitHub and start posting repositories, there are public repositories for anyone to see and also private repositories to have control over who can see them and have access to them.

When you create a repository in GitHub it gives you the commands to connect your local repository with your remote repository. It is important to note that there are two ways to create a repository, the first one is online first, in this case, you have to follow the instructions for cloning the remote repository into your local disk. To be able to do this you have to create an ssh key to access the GitHub servers to be able to download content from the remote repository (pull) or post content to the remote repository when you have made changes to it (push). The second way to create a repository is to create it locally first and then send all its contents and commits to the remote one, for this you have to create the remote repository as well, to have an address to push to but when you create it in GitHub you have to create an empty repository, no README file or anything, and when it is created it will show you the steps to setup your remote repository in your local repository, just remember to select the ssh options, because if you select the HTTPS option you won’t be able to push to that repository.

To generate an ssh key there is a post in the GitHub documentation about how to generate it and how to register it in GitHub. If for some reason the link is no longer available you can check out your setting menu for your GitHub account and look for the keys section.

Now that we have some knowledge about git and cloud repositories let’s talk about some popular workflows to work with git, the two main ones are gitflow and trunk-based workflow but in practice most people use a combination of both. The resulting workflow is that you have a develop branch where all your code is committed, either directly to the develop branch or by merging feature branches after the work on those is finished. Then, when the release time comes, the develop branch is merged into master and that is where the production code lives and gets deployed, and you keep committing to the develop branch in between releases and repeat the process every time you do a release. Sometimes you also have to do a hotfix in production so you do it branching off from master and then merge it into master, but you have to remember after all the work is done, to merge the modified master into develop to include the hotfix and not have two different versions of the code in two branches. With this workflow, the code in the master has to be the same as the one in the develop branch when a release is launched.

Now we know what is git and how to work with it, let’s dig into some basic commands that are the ones that I use on regular basis working as a developer and that will help you get started with git:

Git add: This command adds files to the staging area for the repository. You can add individual files or add all the changed files by using git add.
Git commit: The commit command creates a point in the repository where all the changes are saved and you can go back at any point in the future. You can use the -m switch to add a message directly from the console or you can configure your git to open an editor to write your commit message when the command is run.
Git remote: With this command, you can register the URL for a remote repository you want to send your code, you can do this by running git remote add [name] [URL]. You can also list the registered remote repositories by running git remote -v.
Git push: Now that you have code committed to your repository and a remote repository registered you can send your code to the cloud by running the command git push [remote_name] [local_branch_name], with this it will send all your commits to the remote repository.
Git pull: If you were the one that last changed the remote repository you can continue working, but most of the time you are going to be behind the repository because other contributors have pushed their code too, for this you have to bring or sync up your local repository with the remote one, this is done by running the git pull command, keep in mind that if you run it without specifying anything else this will bring the changes for the branch that you are on.
Git stash: When you made some changes to the code but is not ready to be committed and you have to work on something else either in the same files, maybe you want to try something else, or you have to work on another branch you can put your changes away with git stash, and when you need them back you can do git stash pop to retrieve the changes that you put away.
Git fetch: With fetch, you will poll the remote repository for the recent changes and it will respond with the changes on all the branches that it has, so when you switch to a branch or need a branch that doesn’t exist in your local repository you can pull it.
Git log: This command will show you all the changes made to the repository from the latest to the oldest.
Git diff: With this command, you can see the differences between your changes and the last commit if you run it without any arguments, but if you pass the hashes for two commits it will show you the differences between those two commits
Git checkout: This command will allow you to move to a branch but if you run it with the -b switch it will create the branch if it doesn’t exist. The command is git branch -b [branch_name].
Git merge: This command will combine two branches into one keeping the commits from both branches, to use this command you have to be in a branch and then run git merge [branch_name] to combine the branch that you are specifying into the branch that you are on. This is used mostly to update branches when it has taken too long to develop to prevent conflicts when the work is finished or to introduce changes recently made to the main branch that you need for your branch to run.

I hope this article shined some light into your development journey and now that you know a little more about git, you want to start using it in your projects. Thank you for reading all the way through and if you liked this article give it a clap. Also, check out my other articles, you never know what else you can find useful there.

An introduction to git

References

Written by Mateo mojica

No responses yet