Setting up your own git repository is easy! This episode discusses doing it as a local repository; in other words, it's not world-facing. You can adapt all of this for something that you want to have available via the internet, but you'll probably want to use ssh as your entry point.
Here's the basics of git:
- Install git on both your client machine and server. You probably already have it installed; verify that with the command which git
On the server, configure your git profile:
$ git config --global user.name "Klaatu von Schlacker"
$ git config --global user.email "email@example.com"
Make a git respository. It's conventional to end it in the
suffic .git. After you create it, cd
into it and initialize it as a bare git repository:
$ mkdir codestash.git
$ cd !$
$ git --bare init
Believe it or not, you're done. You've just made a git server. Now let's talk a little about how to actually use it. Now we'll switch gears over to your client machine; in other words, all of this will be done on the machine you normally work on, from which you'll be syncing to the server that we just set up.
The first thing you'll need to do is clone the empty repository to your local machine. This is pretty common; it's how you clone a git repository.
$ git clone 192.168.101.4:~/codestash.git
And then you'd start working on your code. As an example,
let's make a simple example file:
$ echo "gort" > example.txt
So you've just created a new file, but it has not yet been
sync'd with your git repository. But git is still aware of it,
which you can see:
$ git statusGit spits out the fact that sure enough, you have a new, untracked file.
To start tracking all the changes to that file, which is
normally what you'd want to do (or else why are you using
git?), you must add it via git:
$ git add example.txt
OK, so git is tracking that file, but it still isn't sync'd over to the server. This is called a git commit. This, by default, commits everything that is in your add-list (which currently contains one file; example.txt).
It's important to understand that even a git commit doesn't send anything to the server. It's just queuing stuff up on your local machine.
By default, a commit collects everything in your add-list into a new, uniquely identifiable commit instance. That will make a little more sense in a moment or two.
$ git commit
After you commit a file, you'll be asked to write a short commit message for the logs. It defaults to whatever your EDITOR environment variable is set to.
When you're really really ready to commit your changes to the server, then you can push the changes. For the first push only, you must be overly specific about what you are pushing:
$ git push origin master
Now that you've made one push, you can make another change, and simply do:
$ git push
To see what's happened so far, try git log
Once again, that's pretty much it. Those are the basics of git. But we should try something to showcase a little bit of its power:
Let's change our example file. For instance, let's pretend to make a mistake in redirection:
$ cat example.txt
$ echo "klaatu barada nikto" > example.txt
$ cat example.txt
> klaatu barada nikto
Oops! we meant to >> but I only typed one, thus overwriting the contents of our example.txt file. No worries, we can fix it.
$ git checkout example.txt
$ cat example.txt
Git to the rescue.
JessiJames in IRC showed me how to encrypt thumbdrives, etc, with LUKS. It's pretty neat. In this example, we'll assume you're going to create an encrypted thumbdrive. Obviously you could do the same thing on any drive, but if it's something that is needed during boot, please make you know what you're doing.
Plug the thumbdrive into your computer; make sure it's ok to erase the drive, and make sure you know what the drive is called. You can use the usual dmesg | tail to find out. Let's assume we do that, and we see that our thumbdrive is /dev/sdb
Use cfdisk or fdisk to create a new parttition table on the drive. If you don't do this often, use the menu-drive cfdisk
In the end, you should have a thumbdrive with one partition on it; ergo, you've got /dev/sdb and /dev/sdb1
No we set up the encryption. This uses LUKS, which is a part of the LVM suite. So if you don't have those installed, install it before proceeding.
$ cryptsetup luksFormat /dev/sdb1
Not that we're encrypting the partition, not the drive itself.
You'll see a warning that LUKS is going to erase your drive; you must accept if you want to continue. You'll be prompted to create a passphrase, so do that. Don't forget that passphrase; without it, you will never get into that drive again!
So we've encrypted the thumbdrive's partition, but notice that there's no actual filesystem on the drive yet. Obviously for the drive to be of any use, we need to create a filesystem to your computer can save files to it.
$ cryptsetup luksOpen /dev/sdb1 mythumbdrive
Enter your passphrase, and now look in /dev/mapper and you'll see that you've mounted the volume along with any other LVM volumes you might have. Ergo, we now have access to that drive.
There's still no filesystem on it though, so let's create one.
$ mkfs.ext2 -o Linux -L mythumbdrive /dev/mythumbdrive
Now do an ls -lh on /dev/mapper and you'll see that mythumbdrive is actually a symlink to some other dev; probably /dev/dm0. That's the filesystem you can actually mount:
$ su -c 'mount /dev/dm0 /media/hd'
And now the filesystem on the encrypted drive is mounted and can be written to! You can manage that however you want, whether you prefer to add it to fstab as a user read/write volume, or whether you prefer to create a chown'd directory within that filesystem, et cetera.
Note that you don't have to use the drive via the command line if that's not your workflow. Once you've created it, you should be able to plug it in and access it (even enter your passphrase) in the GUI. KDE, I know for a fact, integrates it seamlessly into its device notifier and Dolphin.