I’ve been thinking of getting into open source for the longest time. To get the procrastination out of the way I decided to blog about this journey. And publish the posts!!..oooh scary.
I’m guessing since I’m going to be working with GitHub a lot it’s about time I faced this weird little monster called
Coming from a Java background I used
SVN…a lot. It was simple enough to use at work and with an IDE you didn’t even have to know the commands. But
git has proven a bit more difficult to master mainly because I hadn’t used it as frequently as I may have wanted. Plus it doesn’t seem as easy to understand as
SVN mainly because:
It is a distributed Version Control System (VCS)
- You’ll have a local repository which lives inside a special folder named
.git. With this you can commit changes even when offline.
- You’ll normally (but not necessarily) have a remote, central repository where different collaborators may contribute their code.
- Each of those contributors has an exact clone of the repository on their local workstation.
Local version control
Centralized version control
Distributed version control
This is what
git actually does; it manipulates files in your file system based on commands you give it. It manages everything it does logical in a tree structure . The commands I mentioned help you navigate and manipulate the tree structure. One of these commands is
commit which creates a node in this tree. A node represents a group of changes to files in the project.
Think of the
master branch as container for or a group of nodes(commits) on the tree with the most recent node on top.
HEAD,on the other hand, is a reference to the node the
work space of the repository currently points to. Confusing? Don’t worry it gets clearer.
I have a project I’d like to ‘version’ it using
What if someone gave me a link to a project I want to contribute to?
#Clone the repository.
I want to see what’s happening with my repository
#Check the status of the repository
This prints out some helpful stuff about your repo like:
On branch master
nothing to commit, working directory clean
I have a project. How do I add stuff?
#Create a file
I want to create a new feature in my project
Git is highly optimized for branching and merging quickly. Branches aren’t copies of the working directory folder. Instead they are just another grouping of nodes on the tree.
Git keeps track of branch changes within the same folder as the working directory and makes changes to the working directory when new branch is checked out.
Conventionally new features for a project are created in a branch. Feature branches are then merged into the master branch after testing and then deleted.
Git allows us to do this quickly and easily because no files are actually copied.
#Create new branch
Oh no! I have conflict. How do I merge?
A conflict occurs when two or more sets of changes are made to the same file. For
git this usually happens when you attempt to merge changes from two branches that have changes to the same files. A merge copies nodes of the tree contained within a branch into another branch. Conflicts can be resolved manually by editing the file in conflict and committing it.
#Let's assume I also made a change to the original hello.txt file within the new branch created previously
You should get a message like…
To resolve the conflict…
#Open the file in an editor
You should see something like…
Edit it to look the way you want
N/B: Your conflicts may span multiple lines
I want to go back in time and try some stuff
Git keeps a log of all commits. It keeps SHA references to each commit. This is ideal for jumping back to previous commit. Here’s why…
#List all previous commits. Copy the reference
This prints out a helpful message:
Note: checking out '92225e88'.
A detached HEAD state basically means that the work space is currently not pointing to any container of commits (a branch). This means that if you checkout a branch you’ll lose all commits made here.
Warning: you are leaving 1 commit behind, not connected to
To save your commits you can create a new branch for them in effect putting them into a ‘container’.
I don’t like the way the project looks now. How do I undo the changes?
There are two ways of making this happen:
resetis for changes that haven’t been pushed to a remote repository yet.
git reset --hard "92225e88"
Doing this on pushed changes will cause the shared history of the project to change causing ‘synching’ issues.
revertis for changes that have been pushed to a remote server.
git revert "92225e88"
This creates a commit that removes all changes in the specified commit.
Finally I’m done with my changes. Let’s share it with the world
We’ve been speaking of a remote repository for a while now. After making all your feature changes you may want to share it with the rest of your team.
You will need a
remote for that.
#'origin' is the name you give to your remote
If you cloned the repository then you already have a remote.
#You can list your remotes
N/B: A remote may even be a cloud server(maybe a Quality Assurance server or a Continuous Integration server) which you can deploy to by pushing.
#You can push to a specific branch on remote
- Adding and Committing
#Add and commit a file already added once
- Branching and Checking out
#Branching and checking out in one command
I’ll be writing later on the differences between
push later as well as the mysteries of
rebase and squashing.
- GitK Tool
This is a minimal tool to help you to visually understand your repository
This is one tool I’ve used often in the past. It’s good for all beginners because of the visuals.