Effective And Efficient Git Workflows — Part 1.
When I started working on this guide I had the intention of doing one mega Git post but as I started putting everything together I realized that there is a lot to go through so I decided to break it up into smaller, more digestible posts. This is the first in a series of posts so make sure to follow me so you don’t miss the follow up posts.
Objective
This first post is aimed at both beginners to version control systems(VCS) as well as others switching from a non distributed version control system like SVN to Git. Although it’s an introduction don’t skip this post as it lays the foundation for understanding and working effectively and efficiently with Git.
I have been using Git for more than 12 years now and I have seen many developers fall into the trap of jumping into Git without a good understanding of how it’s structured and works. This usually ends up with developers confused with how to use Git beyond the basic commands resulting in a slow and ineffective use of the tool.
This intro is meant to provide a solid foundation upon which you can build upon. At the end of this post you should have attained a high level understanding of what Git is and why it’s useful in tracking changes and updates in software development projects.
Be patient while you go through this intro as it’s very important that you grasp these concepts. We will start to go deeper into actual commands and use cases in the follow up posts.
Prerequisites
- This post assumes that you have at least a basic understanding of software development because we will focus mainly on the version control aspect of development here.
- Although not needed for this first post it’s useful that you have a basic understanding of the command line as we will use it to run some Git commands in subsequent posts.
What Is A Version Control System?
Version control or source control is a system or software used to track and manage changes in a software project. It tracks changes to the project like new files and changes to existing files among other things.
Version control also allows teams to work on different versions of the project concurrently without interfering with or accidentally overwriting each other’s work.
What Is Git?
Git is a distributed version control system(VCS). It’s a software system that is used to track changes in other software projects. It keeps different versions of your projects as snapshots of the project at any given point in time so you have different versions of your project and also the ability to go back and forth between the different versions without losing any of your work.
Git was created in 2005 by Linus Torvalds who is also the creator of the Linux operating system. He wanted to have a VCS that could cater to the unique needs of the Linux kernel’s open source development model with 100s if not 1000s of different individual contributors distributed all over the globe but still working together on the same open source project.
The distributed part of Git comes from the fact that every developer on the project has a copy of the whole project on their machine so technically there is no central repository. You can recover the whole project from one machine if anything happens to any other copy of the repository.
The Git Project Lifecycle.
Git has different lifecycle layers built into it from what’s on your local computer to anything that’s also shared with other developers. We will go through these layers first before we see how we can navigate and move code and files between them.
Working area or working tree.
This is a copy of one version/branch of the project files that is stored on your local machine for you to modify and to add or delete files as needed. You are free to add, delete and modify any files in the working area without affecting the Git repository. Once you are finished making changes in the working area you can move them to the staging area to tell Git that they are ready to be permanently added to the repository. You don’t have to move everything to the staging area at once but only what is ready to be shared with others.
Staging area.
This is where you move the files that are ready to be permanently added to the repository. You can still have some changes in your working area and they will stay there and not be added with the staged ones as long as you don’t stage them. Moving the files from the staging area to the local repository is called committing in Git terminology.
Local repository.
This a copy of the whole project repository stored on your own machine. Since Git is a distributed VCS it means that every developer has a copy of the whole project repository locally. This copy is stored locally in a .git directory.
Once changes are committed to the local repository they are permanently added to and tracked by Git.
This local copy of the whole repository is kept in sync with the remote repository by updating it with any new changes from a remote repository. Getting updates from the remote repository is called pulling in Git terminology. On the opposite side, sending and sharing your changes to the remote repository is called pushing to the remote.
Important: Although Git is now tracking these changes they are still only on your machine at this point so they can be permanently lost if they are not yet pushed to the remote repository in case of a hard drive failure or losing your computer.
Remote repository.
Fundamentally there is nothing special about the upstream/remote repository as it’s just another copy of the project repository. The only difference is that the “central” repo is usually kept on a server rather than on an individual engineer’s machine. This is done to make sure everyone knows where to push and pull the latest changes from. The server also usually has repository backups and other security features to limit access to only authorized users.
In terms of functionality and contents the remote repo is similar to any other repos on any developer’s local machines. The only difference is everyone knows the network address to it so everyone uses it as the source of truth.
In fact any developer’s machine can be used as the central repository since they are all an exact copy of the project as long as they are current. It’s obviously better to use a more powerful and easily accessible server for this purpose to make it easier to scale when you have several developers on the project.
How The Codebase And Project Files Actual Move Between The Different Git Stages
The following commands are the major commands used to move between the various Git stages that span from making local changes to sharing these with others and also getting other developers’ work into your own local repository.
For now we will go through a high level overview of the most used commands and then go into more details and examples in subsequent posts.
Init
Init is used to create a brand new Git repository. Only use this if the project isn’t being tracked already. See clone below if you need to get a copy of an existing Git repo onto your local machine.
Clone
Cloning is how you get a copy of any Git versioned code from an existing remote repository onto your local machine. Cloning will make an exact copy of the remote repository code on your local machine. It will also create a local Git repository that you can make changes on without affecting the central or remote repository until you are ready to share your changes.
Pulling
Pulling is how you get any new changes that have happened on the remote repository since the last time you took an update from it.
Checkout
After you have cloned or pulled code from the remote repository you still don’t work on the local repository directly. You checkout a branch from the local repository into a working area of your local machine. This is the working directory where you will be making any changes to the codebase. Git will start tracking any changes that you make to the checked out files.
Staging
Git automatically tracks any changes to the files that are in your working directory but you still need to manually stage them before you can commit them into the local repository. This allows you to stage only files that have completed work. So if you made changes to several files in the working directory you have the ability to commit and only share the ones that are ready.
Committing
Committing is when you tell Git that the files you added to the staging area are now ready to be shared with the rest of the team so Git will add them to your local copy of the repository.
Keep in mind that most of what you do in Git is done on the local copy of the repository until you push the changes to the remote repository which is also called the upstream repository. It’s important to make regular pushes to the remote repository just in case your hard drive crashes or something similar.
Pushing/Pulling
Pushing is when you send the changes you committed to the remote repository. Keep in mind that after pushing all the changes you committed locally will now be available to all the other team members so don’t push incomplete work that might introduce bugs to the codebase.
Conclusion
Hopefully this gave you a good solid foundation of how Git is structured. We will go deeper into actual commands and examples in future posts so make sure to follow and also bookmark this post as I will keep updating this with links to subsequent posts.
Feel free to drop a comment below if you have any questions or need clarification on anything in this post.
Part 2 of this series is now live.
