#code control

[nolacom]

RTFM

I'm usually not one to say RTFM, but when you've been banging on a keyboard for 20 minutes and trying every single combination of command line parameter order there is, RTFM already

[norwichtech-blog]

Server-side git - a guide

Using GIT on a server to allow multiple people to work on the same code base

If you're new to git, first work through Using GIT locally on OSX to back-up and track changes to get the hang of the lingo/basic commands

1. On the Server

Make sure your server has the latest version of the code, as this will become the master!

Get an SSH connection to your server. On Mac OSX open Terminal and type:

ssh [email protected]

(I'm assuming a Linux or other Unix flavour server here. If you're using a Windows server I have NO IDEA WHAT YOU ARE DOING)

 Switch to root and get your favourite package manager to install to code e.g. for Ubuntu it's:

sudo apt-get install git-core

Now change directory to the code you wish to share / edit / backup, for example:

cd /www/htdocs

 Start git tracking:

git init git add . git commit

2. On your Local Machine

You also need to install git. (Go get it!: http://code.google.com/p/git-osx-installer/downloads/list?can=3 )

Now you need somewhere to keep your local copy of the code, e.g.

mkdir ~/mycode/

cd ~/mycode/

Now you can clone your server's files, e.g.:

git clone [email protected]:/home/path/to/my/code

Wait for however long it takes to download your working copy of the code...

Now, make some changes then do the usual "git commit -a" to apply them locally.

3. Apply your changes to the server

Have a look at the servers you have configured:

git remote -v

This should at least list the server you cloned your code from, by default called "origin".

Now first you need to merge any changes on the server with your code:

git pull

If it fails, you'll need to find the conflicts, edit the files and recommit them locally, then:

git pull

git push

(Note: you can rename "origin" using "git remote rename origin somethingelse")

An added level of source control can be added by first cloning your local master repository:

git branch -b newbranchname

git checkout newbranchname

Then when you're done:

git merge master

git diff    (then fix shit)

git commit -a

git merge master     (again)

git checkout master

git merge newbranchname

git push origin master

[norwichtech-blog]

Stop GIT being a git - a simple guide to code control

Using GIT locally on OSX to back-up and track changes

This is principally a guide to getting git to work on Mac OSX. Sure, there's plenty of git tutorials online, but I found them esoterically geeky so thought I'd write one that made SENSE (to me anyhow)...

1. What is GIT? This surprisingly unanswered question is a case in point. There's plenty sites in Courier out there explaining the File Status Lifecycle and SSH keys but precious little by way of high level summary. Essentially, you can use it to back up your code (and if you're a one-man-band coder then you're probably just as well sticking to Time Machine)

However, if you're project has expanded to a couple of you working on various files at once you'll know what an UTTER NAUSE it is when you stuff everything back onto the file server / shared drive and it doesn't work. This is where it really gets useful - in telling you who has done what changes and when.

2. Where does it live? git keeps a copy of the directory of code you point it at in it's repository, either locally on your laptop - or on a web-server so a bunch of you can use it (or even the outside world if you're openly-sourcey. Whatever, you'll access it via the command line (via Terminal). There is a bunch of GUI clients if you prefer - or just type

git gui

from Terminal to launch the one that comes with git.

3. Local GIT like I said before, this isn't wholy necessary if you're already using a Time Capsule, but it's good practice with git and does allow you to tag changes with comments if your human memory is not fully functional (as mine isn't).

Fire up Terminal and change directory to something with code in it (e.g. cd ~/Sites/mywebapp). Now type:

git init

Now tell git to add all your files to it copy of your code:

git add .

git commit

It'll ask you to enter a commit message - which you have to do each time you commit. Your Terminal has probably launched your least favourite text-based editor to do this. To switch editor to a different Terminal-based one either follow this brief guide or simply if you prefer to use emacs go for:

git config core.editor emacs

or for TextWrangler:

git config core.editor "edit -w"

Something like "Initial commit for my project" will do fine.

Typing:

git status    tells you what's going on

git diff    tells you (in a hideously geeky way) what the differences are between your version and the last committed version

git log      see what you've done

git log -n4    see what you've done recently without spewing out EVERYTHING

git log -n4 --pretty=oneline    see what you've done in a compact one-line-per-commit way (WHY is this not the default?)

If you don't want to add all changed files, list their filenames instead of "." e.g.:

git add file1.js file2.css

If you want to commit everything you've changed, you don't need to do "git add ." for existing files, only:

git commit -a

If you use some editor like emacs which leaves back-up files strewn around, cd to the root of your code and create a .gitignore file. In it you put the name of each file you wish to ignore on separate lines - or you can use a * wildcard (mine is simply "*~" to catch all of the code.js~ etc files)

you'll probably want to add your .gitignore file too!

git add .gitignore

Retrieving GIT back-ups

OK - that's the basics. Now it gets useful.

To see the differences between 2 commits for a file, use:

git log -p nameofcodefile.php

At first it looks like scrambled sed, but it's fairly straightforward:

- The long 40 character code next to each commit is it's id. 

- each line that starts with "+" was added in that commit

- each line that starts with "-" was removed in that commit

To see who wrote every line in a file, this is cool:

git blame nameofcodefile.php

To rollback to a previous version of your code, use:

git checkout dc4dd42f109aba67a671d61ab6b2d0cfa6ec13fd

substituting your own 40 character id (from a call to git log)

 You are now looking at your files as they are. Any changes you make and then commit WON'T affect the master code, but are committed to a temporary branch. Try doing a change, commit and git log. You can see all of the changes that were made prior to the id you chose, then only the ones you've just committed subsequently.

Now you have a choice - a) keep using your code base you've changed, b) revert back to the original (and chuck your changes), or c) merge the changes:

a) This is called "branching" the code. Formalise your current temporary branch using:

git checkout -b new_branch_name

b) Chuck away your changes by switching to another branch. First you need to know which branch to merge with (likely "master", if you're working through this tutorial). To list all of the branches, type:

git branch using:

Now do:

git checkout master

(replacing master with the branchname you're merging with)

c) Merge your changes. 

git merge branch_name

Whoops! Did you get a "Automatic merge failed; fix conflicts and then commit the result." message that stopped the merge?

Ok, so you need to tell git which code to use. git merge will have listed the merge conflicts to give you a head start. To look at the differences between each one use:

git diff filename.php

Git will list out your code, and litter it with bits that look like this:

++<<<<<<< HEAD + +// This is a new change to index.php +// I did this following checkout of an older version... ++======= + // This was a change that was made to master but I do not have. ++>>>>>>> master

The top bit of this section is the code you've just written (HEAD) and the bottom bit is the original code in the target branch (in this case "master")

Edit the conflicting file (your version, obv) and delete git's diff messages, choosing the code you want to keep. Finally tell git that it's right simply by adding it:

git add index.php

Do a commit and recall "git merge"

Now then, this has merged "master" into YOUR branch. (This is way safer than you screwing up the master branch whilst you fix merge conflicts). The final step is to update the master. Type:

git checkout master

That'll switch you over. DON'T PANIC that all of the code on your hard-disk has reverted to the old version! Now, merge your new branch into master, following the same steps as before:

git merge nameOfYourBranch

Delete your old branch if you like…

git branch -d nameOfYourBranch

If you don't want to start a fight with everyone else working on the master branch, it's probably a good idea to create your own branch:

git branch newbranchname

git checkout newbranchname

Then you can work without affecting anyone else. When you're done it's:

git merge master

git diff    (then fix shit)

git commit -a

git merge master     (again - should work without conflicts this time)

git checkout master

git merge newbranchname

git branch -d newbranchname