Basics
You are new to Git? No problem, we got you covered!
After successful installation, you are ready to start working with Git.
You’ll see that the basics are not that complicated.
First, open up a command line or shell.
This is the most common way we interact with Git, telling it to execute certain operations.
Every operation is prepended by the git keyword.
The following paragraph quickly summarizes the common workflow with git.
Repositories
Repositories are the key element of Git.
From outside, they appear as a regular directory, however it contains some hidden magic and is watched by Git.
We say the folder is “under Git”. Git invisibly maintains three so-called trees for the directory.
- First, the Working Directory is basically the folder we just talked about. It holds all the files.
- Second, the Index is often referred to as the “
staging area”. Inside, we track changes of the working directory. A bundle of changes that are being stored under a single reference is called commit. - Finally, the HEAD points to such a commit. More precisely it specifies the last commit that was made.
Cloning
To get things started, obtain a copy of a repository from a remote URL and store it to any local destination. We call this cloning because essentially, we create a clone of the remote repository on our local machine.
git clone <URL> <destination>
Now, change into the newly created directory.
cd <destination>
You are now inside the first of the three trees, the Working Directory.
Commits
Now, after creating, editing or removing some files in the Working Directory, you can add these changes to the Index. This process is called staging.
git add <filename>
git add *.<type>
git add .
Save these changes by creating a commit. This operation updates the local HEAD. It will take all of your added changes, bundle them together and adds a commit hash on top of it. From now on you can always refer or for instance roll back to this certain commit.
git commit -m "Commit message"
The commit message is a mandatory parameter. It is an important part of Git, as it allows you and your team to quickly recap what purpose a commit had.
Synchronization
By now, you experienced and learned about the basic workflow of Git. That was fairly easy right? However, there’s something important to remember all the time.
All changes to the three trees are made locally unless explicitly being synced with a remote server.
This is not an unnecessary, annoying misconception, but intentional behaviour.
On the one hand, you are able to work without any internet connection, on the other hand, the lack of a connection to the internet can be seen as kind of “safety mechanism”, as anything you screw up is not instantly rolled out to your teammates.
If you want to publish your changes at some point, there are two essential commands to do so.
Pushing
Uploading the latest changes to the remote server is called pushing. This step is required for allowing your teammates to incorporate your latest changes to their local repositories.
git push <remote-alias> <target>
Hereby, origin and the current branch you are working on (mostly master).
To learn more about branching and its benefits, check out the advanced chapter.
Basic Pull
Now, what’s think of the opposite of pushing. You probably guessed it right - it’s pulling. Pulling refers to the process of updating your local repository.
git pull
This operation allows the integration of contributions from your teammates to the codebase by fetching changes from the remote server and merging them with your local work. Occasionally, you may encounter situations where this is not a completely hassle-free process. Learn more about it in the next chapter, were more advanced techniques and features of Git are explained.
Repository Status
While working on the project, we recommend you to check the status of the repository regularly. To do this, type
git status
This command prompts a summary of the changes that you made since the last commit and also informs you about new files.
Beginners Mistakes
We close this chapter by looking at some common beginner mistakes you should avoid.
- Committing and Pushing before Pulling Communication is key! Especially, if you and your teammate are working on the same files. If you try to commit changes to a certain file without incorporating changes to this very file that your teammate pushed earlier, it is possible, that you end up in a merge conflict. Generally speaking, most of the time you should pull first to integrate eventual changes (your local repository is not kept in sync automatically), before you start working and pushing your own commits. Fixing merge conflicts costs time and can be tedious, so you should do your best to avoid them.
- Performing too few or too many commits. Always try to split your work into multiple, evenly spaced commits. You will be more flexible when trying to go back in time, as you will have more “‘checkpoints’” you can reset your repository to.
- Using inappropriate or weak, meaningless commit messages. If you want to figure out what the purpose of the last commit was, commit messages are a helpful way of documentation. Messages should be compact, but very descriptive.
- Storing unrelated material on the repository. For instance, configuration files of your IDE, your new exam results or the latest episode of The Big Bang Theory. For real guys: Not only is this not the purpose of hosting services like Bitbucket or GitHub, but storing big files and committing those to the remote slows down pushing and pulling significantly. Using git to track IDE config files can even lead to unnecessary conflicts with your teammates. Avoid this under all circumstances.