git

GIT the easy guide

It seems the people that I work has different views on how to use git, so I decide to put together a git starter git that hopefully can help others to get started to grow the knowledge of git.

The first thing that you would need to do is to setup git, here are some resources for various environments.

setup

Download git for OSX

Download git for Windows

Download git for Linux

how are you going to use git

the next you need to do is to define how you are going to use git. git can be used in many ways, I use it for instance for the following:

  1. backup of my WordPress website – using a git push model to push changes to GitHub
  2. development work to share git with other developers contributing towards a release.
  3. distributing code updates to remote servers that are using git pull

workflow

your local repository consists of three “trees” maintained by git. the first one is your Working Directory which holds the actual files. the second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you’ve made.

create a new repository

create a new directory, open it and perform a

git init - to create a new git repository

when to use .gitignore

if you create a file in your repository named .gitignore, Git uses it to determine which files and directories to ignore, before you make a commit.

a .gitignore file should be committed into your repository, in order to share the ignore rules with any other users that clone the repository.

the .gitignore file is not added to a repository by default. use your favorite editor to create the .gitignore file then issue a git add .gitignore followed by git commit -m “message” .gitignore.

echo "" > .gitignore
git add .gitignore
git commit -m "message" .gitignore

here is an example of a .gitignore file

*/config/development
*/logs/log-*.php
*/logs/!index.html
*/cache/*
*/cache/!index.html
*/config/*
*/themes/*

 ignore files

To ignore files to be tracked by git that are locally edit, mark all files in a given directory as assume-unchanged.

Step 1:
cd into the folder you want to assume is unchanged,

Step 2:
You can do either this:

git update-index --assume-unchanged $(git ls-files | tr '\n' ' ')

or

git ls-files | tr '\n' ' ' | xargs git update-index --assume-unchanged

Although, with either case, file names with spaces will be problematic. If you have those, you can use this:

git ls-files -z | xargs -0 git update-index --assume-unchanged

If you just want to ignore a file – then you can do this

git update-index --skip-worktree app/themes/bootstrap/views/layouts/index.php

setting up an automatic git pull

I had a requirement of checking the git repo daily for any updates.To set that up on my production environment, I used crontab to do a git pull

Here is how my crontab entry looks like

* 0 * * * su -s /bin/sh root -c 'cd /var/www/html/ && git pull origin master'

You may want to change the directory structure where your website  is located on your server and if you have not set it yet,

git remote set-url origin https://github.com/username/repo.git

I also needed to setup git so it would not ask for a userid and password. That was done by using the git credential helper. Note that credentials would be stored in clear text in your local config using standard credential helper.

Usage examples for credential helper

git config credential.helper store - store the credentials indefinitely
git config credential.helper 'cache --timeout=3600' - stores for 60 minutes

And if you have not set your user name, time to do that.

git config --global user.name "UserName"

checkout a repository

create a working copy of a local repository by running the command

git clone /path/to/repository

when using a remote server, your command will be

git clone username@host:/path/to/repository

add & commit

You can propose changes (add it to the Index) using

git add
git add *

This is the first step in the basic git workflow. To actually commit these changes use

git commit -m "Commit message"

Now the file is committed to the HEAD, but not in your remote repository yet.

pushing changes

Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute

git push origin master

Change master to whatever branch you want to push your changes to.

If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with

git remote add origin

Now you are able to push your changes to the selected remote server

branching

Branches are used to develop features isolated from each other. The master branch is the “default” branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.

create a new branch named “featuresxxx” and switch to it using

git checkout -b featuresxxx

switch back to master

git checkout master

and delete the branch again

git branch -d featuresxxx

a branch is not available to others unless you push the branch to your remote repository

git push origin

checking out a tag

I recently run into a problem with WordPress a plugin was not behaving as expected and I had to roll back and then update the git repository – there are a few ways you could do this – I did the following as I had another developer already committed to the tag that had the faulty plugin in it, so I did not have the option to delete the tag.

to rollback, I checked out the tag that previously was working

git checkout tags/v1.00.83

then I merged the tag with master

git merge -s ours master

then I checked out master

git checkout master

made the updates to the WordPress site and created a new tag

git tag v1.00.85 -f -m "New Version"

then push the tags to the remote repro

git push --tags

there may be more elegant ways to do this, this worked for me.

update & merge

to update your local repository to the newest commit, execute

git pull

in your working directory to fetch and merge remote changes.

to merge another branch into your active branch (e.g. master), use
git merge in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with

git add

before merging changes, you can also preview them by using

git diff

tagging

If you tracking your releases then you should create tags. this is standard practice, which also exists in SVN. You can create a new tag named 1.0.0 by executing

git tag v1.0.1 2aff467678

the 2aff467678 stands for the first 10 characters of the commit id you want to reference with your tag. You can get the commit id by looking at the git commit history.

This will create a new tag with the same name (by overwriting the original).

git tag <tag name> <tag name> -f -m "<new message>"

log

in its simplest form, you can study repository history using.

git log

You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author:

git log --author=torbjorn

To see a very compressed log where each commit is one line:

git log --pretty=oneline

Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:

git log --graph --oneline --decorate --all

See only which files have changed:

git log --name-status

These are just a few of the possible parameters you can use. For more, see

git log --help

Replace local changes

In case you did something wrong, you can replace local changes using the command

git checkout --

this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.

If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this

git fetch origin
git reset --hard origin/master

Recover Deleted Branch

If you by mistake delete a branch locally, you can recover it by doing the following:

git reflog

and find the SHA1 for the commit at the tip of your deleted branch, then just

git checkout [sha]

and then

git checkout -b [branchname]

to recreate the branch, finish by getting the tracking back upstream by

git branch --set-upstream-to=<remote>/<branch> master

useful hints

built-in git GUI

gitk

use colorful git output

git config color.ui true

show log on just one line per commit

git config format.pretty oneline

use interactive adding

git add -i

Can not see remote git

If you can see the remote branch, your collaborators can not see the remote branch when they do

git branch -a

Then they should do the following to add the branch to their local tracking

git push --set-upstream origin <branch>

links & resources

clients

GitHub for Mac (OSX, free)
GitX (L) (OSX, open source)
Tower (OSX)
Source Tree (OSX & Windows, free)

guides

Git Community Book
Think like a git
GitHub Help
A Visual Git Guide


Posted

in

, ,

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *