Month: October 2014

Git Basics, Part 2

As I talked about last week, git is a extremely powerful version control system, mainly used for archiving code. Lets start to understand git, by plunging in and creating our first repository! Lets first create our repository by creating an empty folder in the command line, and cd’ing inside of it.

onionchesse@hunger:$ mkdir GitRepo
onionchesse@hunger:$ ls
GitRepo
onionchesse@hunger:$ cd GitRepo
onionchesse@hunger:$ ls

The output of the last command is nothing, as there is nothing inside this new folder. Lets turn this folder into a git repository with the ‘git init’ command.

onionchesse@hunger:$ git init
Initialized empty Git repository in ~/GitRepo

Cool! Everything inside this folder will be version controlled from here on forth, in the form of commits. The most useful command that you can learn with git is ‘git status’. It will tell you about the current status of the git repository, such as untracked files, changes not committed, and other problems.

onionchesse@hunger:$ git status
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)

As you can see, git is telling us there is ‘nothing to commit’, or no files to track. Lets start by creating an empty test file with ‘hello world’ inside of it:

onionchesse@hunger:$ echo 'Hello W0rld!' > test
onionchesse@hunger:$ ls
test
onionchesse@hunger:$ cat test
Hello W0rld!

Now we have a file that we can version control. In git, you have to add files to a ‘staging’ area before you can commit them, to prevent git from tracking unwanted files. Lets add this file to the git repository and commit it! (By the way, the -m flag adds a message to the commit, to help you keep track of commits.)

onionchesse@hunger:$ git add test
onionchesse@hunger:$ git status
On branch master
Initial commit
Changes to be committed:
 (use "git rm --cached <file>..." to unstage)
 new file: test
onionchesse@hunger:$ git commit -m 'My First commit!'
1 file changed, 1 insertion(+)
create mode 100644 test
onionchesse@hunger:$

And now we have a file that will be version controlled in the future! Lets make a new version by changing it, then recommiting!

onionchesse@hunger:$ echo 'Hello World is for noscopers' > test
onionchesse@hunger:$ git add -u
onionchesse@hunger:$ git commit -m 'Next Commit.'
[master 746f282] Next commit
1 file changed, 1 insertion(+), 1 deletion(-)

The -u flag to add is extremely useful! It adds all files that have been changed. This DOES NOT add new files, however. Lets prove that git is actually keeping versions, by showing history, differences and reverting back to that first commit.

onionchesse@hunger:$ git log
commit 746f282f549b76ad8cff8a7f7bac76576cb47c50
Author: onionchesse <onionchesse@y0l0.com>
Date: Fri Oct 24 23:22:21 2014 -0400

 Next commit

commit 0866cdda0d3bd822b96addf5b0221063f4482f3a
Author: onionchesse <onionchesse@y0l0.com>
Date: Fri Oct 24 23:19:53 2014 -0400

 My first commit!
onionchesse@hunger:$ git reset --hard 0866cdda0
HEAD is now at 0866cdd Next commit
onionchesse@hunger:$ cat test
'Hello W0rld!

The reset command reverts the entire history of the repo back, to a specific version. The –hard flag tells git to overrwrite all changes, to go back to how it actually was at that revision. The string at the end is the version number, which you can spot (the start of) in the output in git log! It sometimes is difficult to remember actually what happened in each release. You can find the differences with the ‘diff’ command. Lets revert back to that second commit and try it out.

onionchesse@hunger:$ git reset --hard 746f2
HEAD is now at 746f282 Next commit
onionchesse@hunger:$ git diff 0866cdda0
diff --git a/test b/test
index 1b63bde..eb9b174 100644
--- a/test
+++ b/test
@@ -1 +1 @@
-Hello W0rld!
+Hello World is for noscopers

The git diff takes in a version number to compare to. As you can see, between these two versions, ‘Hello W0rld!’ was “subtracted” and ‘Hello World is for noscopers’ was “added”. This continues to work across many version numbers as well.

If this doesn’t seem to useful, its about to get extremely useful in Git Basics Part 3, where i’ll talk about collaboration between developers, and branches! In the meantime, practice using git in this simple way! Maybe github may start to make a little more sense than your first time looking at it…

– [onion] chesse

Advertisements

Git Basics, Part 1

Suppose you are using a computer, like you are doing right now. You probably use it most of the time to browse the web, but you also use it to create content. Suppose you are working on an essay, for example. Have you ever been in a situation where you were creating that essay, and you thought, ‘I wish I could just go back to how this essay was before today?’ No? How about that one time where you accidentally deleted all the files on your flash drive… Interested now? Git and its remote service, Github allow you to solve these problems in an extremely elegant fashion, by keeping track of versions whenever you tell it to. This has helped programmers around the world to collaborate on projects, independent of how well they know the developer!

Git is a very complicated but useful piece of software, and fully understanding it can take years of experience. However, this does not stop one from using it productively! To get started on windows, you can install git from here. Here are some terms important for you to learn, ones that you will be using every day when using git:

  1. Commit- In its simplest form, it is a version. When you want to save a version for future reference, or for backup. This can be as simple as a single addition or a large feature set (in a program). If you get confused, read commit as ‘change’
  2. Repository- Where the things you want to version control are. It is usually a folder on your computer. When you make a commit, files from this folder will be added to the repository, and will be kept version controlled. In git, every computer involved has its OWN FULL copy of the repository. To make changes, you commit then distribute them to other members.
  3. Push- A push is where you move commits from one copy of a git repository to another copy (usually on different computers).
  4. Pull- A pull is where you get new commits from another repository, to update your copy.
  5. Branch- This is a slightly advanced concept that describes a point where commits diverge. Suppose you make a commit (change). Then you reset your computer to before you made that commit, and make a different commit. The paths have diverged between these two commits, they are on different branches. Its ok if you dont understand this, I will talk about it more later!
  6. Rebase- A more advanced concept that I will talk about later. (It requires you to know about branches).

Also, keep in mind, git works best with pure text files (like code files). It works, but extremely inefficiently on other types of files. Next week, we will start with creating your first git repository, making a commit, and saving your code (or text) up on github!

– [onion] chesse

Software Licenses

We live in a very interesting world, which all work is kept under control of the creator. Many people (mostly corporations), say this is a good thing, and actively work to extend copyright control. Currently, the life of copyright is well past the life of the creator himself. If one makes a more thorough evaluation, one finds that copyright actually inhibits the growth of new content. In a way, all new content builds on old content, from Disney movies, to artwork, to pieces of software. This last example is an interesting one, as all pieces of software share certain similarities. After all, there are only so many was to write a sort, algorithm, or search. This has lead software into becoming a grey area for a lot of copyright. Many people are fine with sharing their software, however, and want to put their software out there for others to hack on, and a software license will allow people to do that. To use a license, people can simply include the license with the source and the binary files, to show users what rights they have. There are many different types of software licenses, and here is a quick sampling of the most common ones.

The following information is not a substitute for the actual license. For more information, read the full legal text of each license.

The MIT License

The MIT license is probably the easiest to understand: It lets users do anything with your code, as long as they don’t sue you. Large projects don’t use this license too much, as it gives the user absolute freedom to do whatever they want with your software, such as distribute it at a cost or rebrand and redistribute it. It’s a good choice for those who just want to publish a small project to the world, and don’t care about what happens to it whatseover.

The Apache License

The Apache license is very similar to the MIT license, and is used by Apache Free Software projects, such as Hadoop and Apache Web Server. The major differences are that the Apache License gives away Patent rights, and forbids the use of trademarks in derivative software. Use this if you are concerned about the previous two key differences. If you are looking for an alternative, the BSD license might work for you as well!

The Mozilla License

The Mozilla License is used by Firefox and other Mozilla products. It adds a few more restrictions on the more permissive licenses, by requiring that the source must be disclosed with all future derivatives. This prevents companies from using the program within their software suite (and selling it), without giving away the free source and the binaries of the original program.

The GNU General Public License

The GNU License applies even more restrictions by saying that future derivatives or works that use the software must be licensed with the GNU GPL or other free software licenses. This license prevents other companies from using your software in a situation where users are denied the freedoms that you give them in your license, which furthers the open source software movement. However, this can be a downside for people who want their work to be used in proprietary situations, such as most commercial ones. All GNU projects are licensed under this license, such as gimp, gcc, and almost all utilites found in a GNU/Linux system or a GNU Operating System.

– [onion] chesse