Git

Explore articles about git on Life Beyond Fife

Page 3 of 4

push and pull
git

push and pull

The state of a codebase on a git server, whether an origin repo in a server or on someone's laptop, is represented by one or more branches. A commit is a self contained set of code changes (modifications, new, moved and deleted files) made by one developer. A branch is a chronological series of commits that stretches back in time from the most recent change to the beginning of the codebase i.e. the very first commit. The main branch that contains all developers' commits is named master by default. The word branch is appropriate as it fits with the tree...

2 min readRead more →
init, clone and origin
git

init, clone and origin

Hopefully you, and the powers that be at your company, are convinced: git is the future and the way forward. We now begin the journey of understanding the ways in which git is different to server-client VCSs. We assume the user has already installed git and is familiar with navigating directories using the command line. init A git server can hold multiple code repositories known as repos. The simplest way to get started with git is to create a new directory with an empty repo. $ git init MyFirstRepo Congratulations. You created a git repo to hold the version changes...

3 min readRead more →
git

End to Big Bang commits

No matter how agile we get, or small and isolated we try to make our changes, collaborative development will always leave us stepping on each other's toes. When there are big changes to the codebase to be made by multiple developers the key to victory is to selfishly make sure to get yours committed first, otherwise be left open to a three-way merge from hell. Git allows programmers to break-up the merge process into smaller manageable chunks. Having the power of the server on your client means that you don't have to wait until your commit is ready before merging...

2 min readRead more →
git

Backup as often as you like

Have you ever experimented with a few different approaches to solving a tricky problem only later to try to salvage an earlier working state with a mixture of <Ctrl>+Z bashing and consulting the last known state in the VCS server? Or do you get round that by making occasional copies of files or subdirectories, possibly with "\v1" suffixes? Well with git, there's a better way. You wouldn't commit code to the origin repo that was broken, incomplete or didn't pass all unit, integration and acceptance tests. And the same applies to the origin repo with DVCS as well. However, remember...

2 min readRead more →
git

Work on multiple changes concurrently

Some server-client Version Control Systems (VCSs), for instance Perforce, have concepts like shelving where you can isolate changes you make for a bug fix from concurrent changes for a new product feature. In a perfect world we'd only ever work on one task at a time but we know how unrealistic an expectation that is from life. Context switching when programming is a huge productivity killer and any extra tasks that takes up time when moving from one thing to another e.g. juggling changes for different features in one file into separate commits, should be avoided. For users of server-client...

1 min readRead more →
Power of the server in your client
git

Power of the server in your client

The previous generation of Version Control Systems (VCS), like Subversion, have a traditional client-server model. All the functionality relating to version control resides on the server. The client i.e. your local development machine, has access to just a single snapshot of the codebase; nothing can be done with respect to versioning without access to the VCS server. [](/images/originals/traditional-VCS.png) Git, however, is a Distributed Version Control System (DVCS) - there is no server-client relationship because every machine that has git installed is itself a server. What was previously your dumb client becomes a fully fledged server. Any ability your company repo...

2 min readRead more →