Things i have learnt in using git.
Replies: 1   Views: 1518  Subscribers: 0

Posted by reece · 25-05-2012 - 16:04

Just thought i would take a moment to both share with the CC community and make a note of some of the things i have learnt while using git.

I added an entry to my blog some time ago detailing my basic git workflow, its nothing fancy but is a nice starter if your just getting to grips with the basics, i find it helps to take notes of your workflow. You can read my original entry ­here­

­Changing the remote url of your git repository.­

You can determine what the remote url of your repository is by typing:

$ git remote -v­
Which should output something like: ­
origin	[email protected]:codeconsortium/CCDNSandBox.git (fetch)
origin	[email protected]:codeconsortium/CCDNSandBox.git (push)­
That is the regular output for a normal git setup, but if your using SSH or something else to push/pull then expect something slightly different. If your not behind some super anal corporate firewall and your having issues pushing commits then change your remote urls to something similar to the above (steps shown below). You can change your remote repository by opening the text file .git/config and changing the url setting. i.e: ­
$ vi .git/config­
Assuming you wish you use vi, otherwise you can just use nano/pico or any other editor of your choice. The full context looks like this: ­
­[core]­repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
	ignorecase = true
[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = [email protected]:codeconsortium/CCDNSandBox.git
[branch "master"]
	remote = origin
	merge = refs/heads/master­
So the part you would want to change is ­url­ under ­[remote "origin"]­ ­Managing branches.­ 1) create a branch. (Call newFeature whatever you like [e.g: feature/addCheckbox]) ­
$ git checkout -b feature/newFeature­
2) add new files and commit. ­
$ git add ./*­
$ git commit -a­
3) push to github. ­
$ git push -u origin feature/newFeature­
4) switch to the new branch of github then PR and merge. 5) pull update from github with merged changes. ­
$ git pull origin master­
­If your having issues with merging or pushing because remote is ahead, you can do this.­ First pull from remote. ­
$ git pull origin­
­or if this gives you issues, then you can do it manually to resolve conflicts.­ ­
$ git fetch origin
$ git merge <feature/newFeature>­
­If that fails, you can resolve un-merged commits like this:­ ­
$ git add ./*
$ git commit -a
$ git push -u origin master­
That should get your remote up to date on the merges. Whenever you do local merges, you need to do a new commit before pushing. ­Adding new changes to a new branch after changes were made.­ You can decide after you have made changes to add them to a new branch without resetting your work. You just checkout a new branch as per usual. ­
$ git checkout -b <feature/newFeature>­
Then once you finished your work you add and commit as per usual. ­Delete remote branch on remote git repository (i.e github etc).­ You need git 1.7.0 and up to do this: ­
$ git push origin --delete <branch>­
where <branch> is the name of your branch on the remote. You can push like this without any new commits, so even if remote is in sync with local. ­Create a new branch from (n)th commit­ Use the log to find the commit you want to branch from, then get the hash of that commit. You can find the hash by typing to following and finding the commit your looking for: ­
$ git log­
You can always filter that through a grep if you know roughly what the commit message was. Then enter: ­
$ git branch <feature/newFeature> <sha1-of-commit>­
You should then have a new branch from the point of the commit by its sha. ­Replace the contents of the parent directory with a child directory within the git repo­ This somewhat re-writes history and in the process the other sub directories will be removed from the repository. This is very dangerous and you should take caution when using this. I highly recommend making a backup prior to using this. ­
$ cp <your_repo> ./backup­
This is a good approach for when you want to split a repository into several separate repositories. ­
$ git filter-branch --subdirectory-filter <your-sub-directory> -- --all­
Thats a method i used myself to split some repositories up recently. A lot of this was prompted by the research i had to do for a bout of recent git work getting my repositories in order, i will list some of the resources i found on my travels so that you can check the sources for yourself. Though everything seemed to work fine for me you may find some other useful instructions on these links. ­Git Reference­ ­git-branch(1) - Linux man page­ ­list remote branches­ ­ branching & merging­ ­How to change a remote repository URI using Git?­ ­branch from a previous commit using git­ ­Git pull certain branch from github­ ­How do I delete a Git branch both locally and in Github?­ Enjoy and take care when using some of the more powerful git commands. Don't be afraid to ask for help before trying risky things with your git repositories.­

Posted by reece · 17-06-2012 - 04:29

Edited by reece · 12-11-2012 - 05:09
Since my last post i learnt some more bits about git that i needed to use.

The first issue arose when i discovered that my webserver is using a case-sensitive filesystem, where as my desktop machine running Mac OS X is using a case-insensitive filesystem. This meant that code running locally worked fine, but once pushed to the server nothing would work. Obviously this was a big issue. I worked out in the end that git does not care about case sensitivity by default, so if you change the name of a directory or file only by case but the characters remain the same, it won't detect the changes. To resolve this you have to change gits settings. For each repository go into the git config and change the setting core.ignorecase to false.

$ git config core.ignorecase false­
Started using tags recently also, and the basic usage is pretty simple actually. You can list the tags made via: ­
$ git tag -l­
And then add a new tag by: ­
$ git tag -a v1.0­
Where "v1.0" is the name of your tag, this will also open a text editor, there you should add an indepth description of what this version offers. Feel free to put whatever you like in your tags, though they are most commonly used to reference a version. Once you have pushed your updates to remote, the tags for some reason won't get pushed with it. So you will need to use this after pushing changes. ­
$ git push --tags origin­
If you are having issues pushing tags, you can add the "-f" parameter to the end to get it to push without any nonsense. ­
$ git push --tags origin -f­