An Introduction to Git, the most popular system for managing different versions of your code and an essential skill for industry-standard software development. This is definitely a skill you don't want to be without and this workshop will take you from rookie to rebaser in no time.
We'll be covering:
This workshop assumes:
First thing you will need to do, is install Git! If you already have it installed skip to the next section, if not, refer to the relevant platforms below:
Go here: https://git-scm.com/download/win
Follow the instructions, leave everything on its default setting.
Go here: https://git-scm.com/download/mac
Go here: https://git-scm.com/download/linux
If you are on Windows, for simplicity, open bash-for-windows and type:
git config --global core.editor notepad
This is also demonstrated in the video tutorial
If you are other platforms, the choices available are a lot more flexible.
To change the default text-editor for git commit messages just do the following:
git config --global core.editor "editor_name"
git config --global core.editor "gedit"
Some need custom commands, which you will find on an editor's respective website. Here are some common examples:
git config --global core.editor "atom --wait"
git config --global core.editor "subl -n -w"
Although you need to install subl for that to work.
Follow along with this video to setup everything you need for the workshop, the steps are also listed below.
git add <file_name.txt>, where
<file_name.txt>is the name of the file containing your Haiku!
git config --global user.email "email@example.com"followed by
git config --global user.name "Your Name"
git commit, in the text editor, simply add the line: "Add YourName's Haiku". Where, YourName is, your name.
git pushin the terminal, and you are done!
There is no standard way to write a Git commit message. If you look at various repositories around the web, (eg. the Linux Kernel, Dolphin Emulator) you will find not all commit messages are consistent.
However, you will notice a common rule:
Write an imperative title that is less than 50 chars
As a good rule of thumb, try to think if it will fit as
part of the sentence "This commit will...", eg. "This commit will
Add the hunklepunkle feature"
Read this blog post for justification of why to do this.
The body of the commit message can be as long as you want it to be! (but each line should be less than 72 characters) You can write in any format as long as you give a description of what your changes do and, most importantly, why the changes were made. Don't forget to leave a blank line between the first paragraph and the title!
Some repositories will require commits to be signed off, which can go at the bottom. You will see this a lot in Linux Kernel commits. In fact, the links above have good examples of commit messages! Although not every single message follows this format, you will find most of them do.
Provided Git messages have been written to a consistent format, the Git log is
an incredibly useful tool. Here are a few useful examples of
git log with
git log -2:
commit dec1c8344fdfd20f1247bfb9cc9b8035287b767a Author: Example Author <firstname.lastname@example.org> Date: Sun Feb 21 17:56:23 2016 +0000 Overload SaveReader to allow loading from streams All the SaveReader methods now have alternative versions where you can pass an InputStream and they will read a save from that. commit 2ed25caf975beb8b8657912d72081afa98fda799 Author: Example Author <email@example.com> Date: Mon Feb 8 13:37:22 2016 +0000 Fix typo in README.md.
git log --pretty=format:"%h %s":
929757e Make example be correct 870d7ee Add conversion tool for .txt preview to .html preview and its output 3874baa Merge branch 'master' of https://github.com/EchoCam/DynamicNarrative.git a72cac5 Rename file 7ed0fed Change default logging level to none 28fe093 Fix Scooby Doo text task 4ce23c4 Change names 1b3fb15 Add final story
git log --pretty=format:"%h %s" --graph:
* 929757e Make example be correct * 870d7ee Add conversion tool for .txt preview to .html preview and its output * 3874baa Merge branch 'master' of https://github.com/EchoCam/DynamicNarrative.git |\ | * 7ed0fed Change default logging level to none * | a72cac5 Rename file |/ * 28fe093 Fix Scooby Doo text task * 4ce23c4 Change names * 1b3fb15 Add final story
Find out more on the official Git website.
Git rebasing is a clever way of updating one branch with another branch's new commits. The way it works is by finding the common history of the current branch and the one being rebased-in. Undoing the current branches commits until then and then applying them on top of the branch being rebased-in.
However, as it changes commit-history, it should only be used on branches that no one else can see.
Merging is safer then rebasing but can make slightly more nasty commit histories.
A good place to learn more is http://pcottle.github.io/learnGitBranching/
Git blame is a powerful tool to work-out who changed a piece of code and who is responsible for certain aspects to it. You can find out more abuot git blame here.
The most easy way to use it is:
git blame -L<start>,<end> path/to/file
git blame -L134,150 README.md
To show lines 134 to 150 in README.md
You can find out more about Git blame here.
git reset vs
Git reset has two different scopes depending on the parameters passed, commit-level and file-level. We will only cover the former, which is when you pass a specific commit as an argument to the command.
At a commit level, git reset will move the tip of a branch to a different commit, so is very dangerous! It is an easy way to 'undo' commits that you haven't yet made public and definetely do not want the history of in any way.
Another use of git reset, is using 'strength' flags. Such as:
--soft, this won't affect the staged snapshot or current working directory
--hard, this will replace both the staged snapshot and current working directory.
So just doing
git reset --hard without anything else is a useful way of
saying "I'm unhappy with my uncommitted changes, let's start afresh."
Git revert is like a safe reset. You simply pass it a specific commit and it will add a new commit such that it has the same file-contents as that commit, but appends it to the end of the current branch rather then rolling everything back, preserving history.
A useful explanation can be found here. It also covers Git revert and other aspects not mentioned here!
Often when working on a project, there will be plenty of files where you are not concerned about the history and changes made. For example, when working on a C++ project, you will have executable files and '.o' files to actually run the code which need to be remade every time the code changes. It does not make sense to include those in a repository as you never edit them directly, and anyone else looking at your code can easily generate them again.
For this reason, Git allows you to add a file called
.gitignore where you can put filenames that you do not want to show up anywhere in the git repository. This will even prevent them from showing up from commands like
git status, so it is like those files don't even exist from git's perspective! People have even created common templates for .gitignore files such as a C++ one that will automatically ignore all files ending in '.o' (along with a bunch of other stuff). See https://www.gitignore.io for these great templates!
Since this is not covered in the workshop, more info can be found here