Git and GitHub for SVN developers

My latest post on contribution tips I learned from scribu was mostly influenced by his work on GitHub on projects such as WP-CLI or wp-posts-to-posts, and his setup over there. I also had a few related contribution-related posts before than (and several more to come in the next few months). Ajay commented on one of them asking for some tips for migrating his work to GitHub (while he has numerous plugins on WordPress.org now). I’ll post some of my favorite links I send to fellow colleagues starting with Git.

My first SVN-revisioned work was in 2006 and I started working with Git in 2010. Most developers quickly get involved in the missionary for Git and I do agree with most factors, even though I have two or three things I like on SVN as well (such as being able to do svn up and get all your manually deleted files easily without breaking other stuff, or committing in a subfolder only the files in that folder by default).

Git and GitHub

Since that’s another tricky mistake (similar to the difference between WordPress.org and WordPress.com), a few words on that.

What the Git website would say about Git:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

GitHub, on the other hand, is a platform, or even a social network for developers using Git for their projects. It adds some fancy UI, ability to follow other developers, to view project files online (with their diffs, commits, revisions), to easily play with pull requests, submit and discuss issues, and so forth. Other source hosting platforms do the same (with other subset of features and UI flow) such as Bitbucket and you can set your simplified GitHub-alike source hosting social platform on your server with the Ruby-driven Gitorious project. GitHub is just the coolest according to many and where many serious Open Source projects are being maintained.

You can have a local Git repository or synchronizing data between you and your website on your hosting server without being registered on GitHub and using their services at all.

Working with Git on GitHub

I use Git almost everywhere locally, just to keep track on my local changes, and then migrate some of them to GitHub if appropriate. It’s super easy to set locally and quite easy to get your code on GitHub as well.

For example, if you register an account on GitHub and start a new project, the moment you save the project settings you are redirected to a page that displays that sort of information:

mpeshev-some-new-project

 

Generally guiding you step-by-step it allows you to submit the first project of yours.

In my opinion, the majority of the people work on simple projects, developed by one up to three people per project, where the work is pretty much straight forward and 95% of the work is going in the same direction. Especially locally. When introducing the people I work with (freelancers) to GitHub, I ask them to start a project locally and work with it for a bit to get used to Git, and then easily switch to GitHub.

What a local project would require then?

If we have a folder with code snippets that we want to sync (as a small project or a bunch of snippets that you use for your WooCommerce site for example), you can navigate to your snippets folder and run the following scenario:


# List all our snippets

[nofearinc@nofearinc snippets]$ ls
snippets-base.php snippets-cart.php snippets-payment.php

# Init a new Git repository
[nofearinc@nofearinc snippets]$ git init
Initialized empty Git repository in /home/nofearinc/projects/snippets/.git/

#Check the repository status
[nofearinc@nofearinc snippets]$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# snippets-base.php
# snippets-cart.php
# snippets-payment.php
nothing added to commit but untracked files present (use "git add" to track)

# Add all files in the folder to the repository
[nofearinc@nofearinc snippets]$ git add .
[nofearinc@nofearinc snippets]$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: snippets-base.php
# new file: snippets-cart.php
# new file: snippets-payment.php
#

# Commit them (store a snapshot of our current state of files)
[nofearinc@nofearinc snippets]$ git commit -m "Initial commit for our functions"
[master (root-commit) 3000a90] Initial commit for our functions
2 files changed, 21 insertions(+)
create mode 100644 snippets-base.php
create mode 100644 snippets-cart.php
create mode 100644 snippets-payment.php
[nofearinc@nofearinc snippets]$ git status
# On branch master
nothing to commit (working directory clean)

# Add a new function to one of our snippets
[nofearinc@nofearinc snippets]$ vim snippets-cart.php
[nofearinc@nofearinc snippets]$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: snippets-cart.php
#
no changes added to commit (use "git add" and/or "git commit -a")

# Check what has been updated in our repository
[nofearinc@nofearinc snippets]$ git diff
diff --git a/snippets-cart.php b/snippets-cart.php
index 5992fda..3fc3802 100644
--- a/snippets-cart.php
+++ b/snippets-cart.php
@@ -10,3 +10,7 @@ function get_price() {

return $price;
}
+
+function new_function() {
+ return "I am a new function!";
+}

# Add the file to the new commit candidate and commit a new snapshot
[nofearinc@nofearinc snippets]$ git add snippets-cart.php
[nofearinc@nofearinc snippets]$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: snippets-cart.php
#
[nofearinc@nofearinc snippets]$ git commit -m "Update snippets cart code"
[master bb5429f] Update snippets cart code
1 file changed, 4 insertions(+)

# Check the list of latest Git revisions (you can get back later)
[nofearinc@nofearinc snippets]$ git reflog
bb5429f HEAD@{0}: commit: Update snippets cart code
3000a90 HEAD@{1}: commit (initial): Initial commit for our functions
[nofearinc@nofearinc snippets]$

Now, this is very basic and does work for starters. Later we could git checkout or revert a file to a previous revision, or a new branch, in a collaboration we also have to pull others’ changes and push our own to the remote repository. But that gets easier when you’re used to the idea of Git and managing your own files, then collaboration comes in action.

Still, it requires some time to get used to the collaboration itself and not messing up with the Git project. Git is more complex in terms of a larger number of commands and features (compared to SVN) so it requires some learning and attention before it gets simply awesome.

Git/GitHub learning resources

Those are some of my favorite links when it comes to learning Git or how to play with GitHub.

These two I’ve sent to at least a dozen developers to start with:

The other quite helpful ones are for setting Git, the Git book and the guide for SVN users:

I’m an Eclipse guy (even though I use Git only through shell) so a cheatsheet and a tool for Eclipse developers:

There are some UI tools for Windows (such as TortoiseGit) and Mac OS, you could try them if you want (I can’t share experience with them except for some weird conflicts and overriding files through them seen with my interns).

Git for SVN-versioned WordPress plugins/projects

Normally when I sync a WordPress plugin with my GitHub repo, I’m doing a very simple thing – checkout of the SVN repo, initializing a Git repo inside and then committing to Git or to SVN depending on what I need to sync in particular. It works perfectly for me since I prefer to commit to SVN less regularly then I do to GitHub.  Other folks went an extra mile by using some of the helper sync tools that exist:

Why should I care about Git?

If you read the entire post, you probably care about Git already. However, while SVN is the version control system of choice for WordPress for now, the Core team has announced that an official Git version will be maintained as well, and dozens of WordPress core synchronized clones have existed on GitHub for a while. Contributing to plugins is easier with GitHub as it allows you to issue a pull request to a plugin (sending a version with your patch in it) that could be merged with one click by the plugin author. You can also fork a project and develop your own version if needed, merging latest updates from the original project.

There are other perks in using Git too, such as:

  • working with submodules (even if you need to be careful with them) for related sub-projects
  • branches are seamlessly switched behind the curtains in a sweet way
  • there are lots of hooks for extra code to be attached for testing, deployment etc (as pre-commit hooks)
  • numerous tools have been relying on Git versioning to facilitate deployment or integration/testing later

And the more important thing is – working as much as possible transparently by submitting code to GitHub or Bitbucket would allow for code improvements from other developers, helping users and developers with snippets and projects to use without reinventing the wheel as well. Your clients would be able to verify your activity and validate your code and appreciate your skills upfront. You’ll probably get to meet and work with some awesome developers on the way and improve your skills in development, versioning, testing, integration.

So, have you been using Git/GitHub already? And would that make sense for you?

6 thoughts on “Git and GitHub for SVN developers

  1. Mario, thanks for the mention and the detailed tutorial. I got a good amount of reading to do. Am going to start off with one of the smaller plugins that I can afford to mess up!

    1. Glad that’s helpful! I had a gist with some notes and links for Git and I decided to finally throw them in a post so that other people could take advantage too.
      Just push one of your plugins there, then another one and that would do it. You can always revert to an older version and resubmit, etc so it’s not a biggie.

  2. Hi Mario,

    thx for this blog. What I also like about Git in general is that you have all the sources locally – including the history :). This makes us developers to be more flexibel and independent :).

    I have also wrote a blog and tried to outline Git and Github about the underlying process and what it means in the way what tool we use. Check here: http://www.pointsoftware.ch/de/git-and-github-tooling-your-software-workflow-and-development-life-cycle/

    HTH, Tai

Your thoughts?