Skip to content

OPW – Forking and Creating a New Branch in Git and GitHub

January 8, 2013

This week, we are working on getting familiarized with Git and GitHub, and writing up some more detailed documentation to facilitate future deployments of TidePools. I am a complete n00b to Git and GitHub, so here are a few of my notes about them to help me keep things straight. I’m posting them here in the hopes that they may be useful to others, as well.

The TidePools code was recently moved here:

https://github.com/opentechinstitute/TidePools

I was added to the organization as a team member and given permissions to push and pull. I was told that the preferred way to contribute for this project is to add branches, which will then be reviewed before being merged. I didn’t know where to start, and while GitHub’s tutorials are pretty good, I had to read between the lines to figure out how to set up proper branching. Below are the steps I used. I tested functionality by making small modifications to the README file and then checking whether the changes were reflected on GitHub.

The first step was to log in to the GitHub site, go to the TidePools repository on OTI (linked above), click the Fork button at the top, and tell it to fork to g33kgrrl. That creates a copy of the code in my GitHub repositories. Then I make a copy of the forked repository on my local machine:

g33kgrrl@saturn:~/TidePools$ mkdir fork
g33kgrrl@saturn:~/TidePools$ cd fork
g33kgrrl@saturn:~/TidePools/fork$ git clone https://github.com/g33kgrrl/TidePools.git
Cloning into TidePools...
remote: Counting objects: 1788, done.
remote: Compressing objects: 100% (1734/1734), done.
remote: Total 1788 (delta 63), reused 1778 (delta 53)
Receiving objects: 100% (1788/1788), 50.49 MiB | 280 KiB/s, done.
Resolving deltas: 100% (63/63), done.
g33kgrrl@saturn:~/TidePools/fork$ cd TidePools

Now I add the upstream, and if I understand correctly, grab any changes to my local machine (there won’t be any at this point, of course), and list the files to see if it looks like everything is there:

g33kgrrl@saturn:~/TidePools/fork/TidePools$ git remote add upstream https://github.com/opentechinstitute/TidePools.git
g33kgrrl@saturn:~/TidePools/fork/TidePools$ git fetch upstream
From https://github.com/opentechinstitute/TidePools
* [new branch] master -> upstream/master
g33kgrrl@saturn:~/TidePools/fork/TidePools$ ls
1.0.0 GNU-PL-3.0.txt js redhook.html
boundingbox.html images php tidepools_open.html
css index.html README

Next, I create a branch called ‘g33kgrrldocs’ and designate that as my workspace. (Note that the ‘M README’ line appears because I’ve gotten a little ahead of myself by modifying and adding the README file as described in the steps to follow.) Here’s how that looks:

g33kgrrl@saturn:~/TidePools/fork/TidePools$ git branch g33kgrrldocs
g33kgrrl@saturn:~/TidePools/fork/TidePools$ git checkout g33kgrrldocs
M README
Switched to branch 'g33kgrrldocs'

Now, as a test, I add a line “This is a test” at the top of the README file, and save the change. I used vi, but gedit or any other editor would work fine, too. Now I want to create a branch, switch to it, and push the branch and changes to GitHub:

g33kgrrl@saturn:~/TidePools/fork/TidePools$ vi README
g33kgrrl@saturn:~/TidePools/fork/TidePools$ git add README
g33kgrrl@saturn:~/TidePools/fork/TidePools$ git commit -m 'test commit'
[g33kgrrldocs 780e0a6] test commit
1 files changed, 3 insertions(+), 1 deletions(-)
g33kgrrl@saturn:~/TidePools/fork/TidePools$ git push origin g33kgrrldocs
Username:
Password:
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 302 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To https://github.com/g33kgrrl/TidePools.git
* [new branch] g33kgrrldocs -> g33kgrrldocs

That’s it. I go back to my GitHub page, look under my forked TidePools repository, and under the file listing it shows:

README | 20 minutes ago | test commit | [g33kgrrl]

Now that I know how to create a branch, I’m all set to make my own changes without disrupting the original project. When I’ve added a new feature and worked out any bugs, I can send a pull request (by clicking the Pull Request button on the main project site) to ask Jonathan to grab my changes and review them before merging them with the main project. Pretty nifty, eh?

P.S. – If you know a formatting tag I can use to get WordPress to stop converting the URLs in my code blocks to clickable links, I’d be most grateful if you would share it here. I have yet to find one, and I’ve already spent too much time trying to hunt one down. Thanks!

Ω

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: