In these notes I will go over git command line basics
The GUIs can only do so much, the underlying knowledge of the command line could be very useful.
Git is a distributed version control system. Rather than a central version control system.
What’s the difference?
A central version control system can be described with the following diagram:
This is a nice simple solution to version control as users can simply check in and out as they please. But it brings up some problems. One of the biggest problems here is that the files you download have no additional version information, they’re just the plain files. An example where this becomes an issue is if the central server goes offline and you only have the files you currently downloaded and no additional version information, like some piece of code you might want to use from a previous version.
If something happens to this central repository or it gets corrupted if there’s no backup all the data will be gone.
The following diagram shows a distributed version control system:
In this situation everyone has a complete local repository, while there is still a remote repository. But your local repository should have the latest version of the remote repository at the time they were synced.
You can still view every change that was made to the repository locally.
If something horrible happened to the remote repository every developer who has a copy can contribute to the restoration.
First step after an installation is to check the version:
Setting up config values is also important
it’s also possible to get help with this syntax:
This works with any git action.
There are multiple reasons someone might use git.
If there is a local codebase you wish to track a local codebase this git init command is what you need:
The git init command by default will create a .git directory in the current directory.
This can be changed by supplying a path to git;
git init <path>
This .git directory contains everything that is related to our repository. If we ever have to stop tracking our local project with git, all we have to do is
rm -rf .git
The git status command gives us some important information about untracked files. There are a lot of files that might contain personal information.
The .project file is a file that we don’t want other people to see.
What is a tracked and untracked file?
For a simple definition, tracked files are files that git is aware of. When changes are made to those tracked files, git can track those changes.
We can use
git add
To add files
To ignore certain files in the git repository, we must create a .gitignore file
touch .gitignore
The gitignore file is just a simple text file we can add files that we want git to ignore. The files in gitignore also support glob syntax, i.e. *, ?, or [].
Now running git status will not show .project anymore, instead the .gitignore file appears
We want to commit the gitignore file because we want git to be aware of what files we need to exclude from commits.
These are the three states we need to know about. Right now we are currently in the working directory state. This means that untracked and modified files will be here.
The Staging area is where we organize what we want to be committed. The purpose of this is so we can choose what we want to be committed. This allows us to make individual commits. The benefit of individual commits is that it allows us to be much more detailed with the information we supply with each git. It’s bad practice to commit lots of files without providing adequate information on what they were.
Adding all files to the staging area and then checking the staging area with the status command.
Additionally running
git reset
Will remove everything from the staging area.
Just like git add it’s also possible to specify specific files or folders.
The following is the process to make an actual commit:
The -m is the message that will go along with the commit.
git log
git log will show the log of the git commit
This shows us a log of all the commits that have been done to the repository.
In this example we have successfully made changes and committed those changes to the repository.
Cloning a repository is necessary for any kind of distributed version control system.
The primary ways we can clone a repo
These are the primary ways to clone a repository.
These are some commands we can use to view information about that local repository:
git remove -v
This command will provide important information about where the original repository was, if it’s a local file it will provide the relative path from the current instance.
If it’s a remote server or something it will show the full url
Quick note on branches:
The master branch is the default branch, but you can make your own branches
git branch -a
This command will list all of the branches in our repository. Not only locally but remotely as well.
How do we push a change to a remote repository?
The first step is using
git diff
This shows us all of the changes that were made to the code.
If we modify a file from the remote repository we downloaded and run git status on it, it will show us the file has been modified. If we go back to the different states this happens when a file is already in the staging area but has been modified.
Now if we run git add -A it will show modified in green instead of red.
Now finally we are able to commit the repository with git commit -m “message”
People often forget to git pull before they git push, but when working on a project that could have multiple developers who are pushing code to that remote repository, while we’ve been working on our own features.
git pull orgin master
This command will simply pull and update your repository with any changes that have been made to the remote repository.
Now we are ready to push with
git push orgin master
A common workflow that developers might use is branching
The syntax for creating a branch is git branch <name-of-branch>
This here shows us the
git branch calc-devide
command as well as just a plain git branch without the name, which shows us the current branches.
The asterisk represents the current branch we are working on.
to change the working breach we can use the
git checkout calc-divide
This will give us access to the calc-divide branch as shown here:
If we make changes to files now, if we add those changes to the staging area they will only be there for that current branch, and the same goes with commits, any commit made to the local branch will not affect the master branch.
Now the syntax for pushing a branch to the remote repository for calc-divide is
git push -u origin calc-divide
In essence the -u origin option just tells git that we want to associate the local branch with the remote branch or the “origin” or something like that probably.
This means that when we are in the branch we can just use git push and git pull without specifying the branch every time.
the output from a successful push from a branch should look like the following:
And the git branch -a command simply shows us our branches, but with this we can also see remote branches, in this case they’re in red:
This is usually what happens when developers ship their code out, they put it in a “test” branch that then gets merged with master when all the unit tests have been completed.
This is the process for merging a branch, in this case it’s with the master branch.
by checking out to master we switch to our master branch, by pulling we ensure that everything is up-to-date. It’s always good practice to get in the habit of pulling before pushing.
We then use this command:
git branch --merged
This command here will list out the branches that we’ve merged in so far
In this case nothing comes up because nothing has been merged with master yet.
To actually merge it we use:
git merge calc-divide
command which simply takes a branch and merges it/combines it with the current branch.
The output here shows us what was changed, in this case it was the calc.py function that changed.
Now that the changes have been merged we can now push those changes to the remote master branch with the command:
git push origin master
The reason that no -u option is used here is because when a repository is cloned the master branches are already linked, this is why when just saying git push or git pull it defaults to master. In reality the origin isn’t even needed here.
Once a feature is done we often want to delete a branch.
The output of the original command that we used to check what had or hadn't been merged now shows us the calc-divide branch is present:
Now we are ready to delete that branch since it’s no longer necessary.
This can be done with the -d option here:
We deleted our local branch but we didn’t delete our remote branch, this can be done with the following syntax:
git push origin --delete calc-divide
Now if we run a git branch -a we can see there is only the master branch locally and remotely:
This information might be overwhelming but when it gets stuck in your head from repetition it can get a lot easier.
