Technical information on this site may be out of date : no updates since 2015
git stash is a great way to save work switch branch and then get back your half completed work from earlier
But I work on many projects, am often playing around with something, get pulled onto the next thing - and I often have stashed work kicking around
By default git stash saves the work but the git list just gives some id for each stash like
The branching strategy I’ve found most effective and flexible is to use one branch per release version that is used for integration and feature branches off these for everything else.
It’s hard to visualise and I’ve tried drawing graphs but once I build in enough features to make the graph meaningful it is no longer easy to interpret.
I used to use subversion and svnmerge a lot, and there’s just one thing I miss about it. Now svnmerge is a tool to bolt on merge tracking to svn, and gits merge tracking is vastly better in many ways. But the one thing that svnmerge allowed me to do that was cool and doesn’t have a real equivalent in git is to block commits
I’m working on a project where I find I want to semi-regularly adjust a config file for local testing, but want to be sure I don’t commit that file by mistake.
Seems the best approach is
git update-index --skip-worktree $filename
This tells git to skip this file when I push, if the remote file changes it will warn me
$new_branch=$1 # passed as param
current_branch="$(git symbolic-ref HEAD 2>/dev/null)"
current_branch=${current_branch##refs/heads/}
current_id=$(git rev-parse --short origin/$current_branch)
new_id=$(git rev-parse --short origin/$new_branch)
last_tag=$(git describe --abbrev=0 --tags)
Git has the concept of both submodules and subtrees, there seem to be some problems with each solution, nether being well loved as far as I can see.
Both add significant complexity to a project, and require extra care - but the alternative is monolithic projects or a lot of copy-pasting.
Submodules allow another git repo to be nested inside the main one, you can then commit to either repo from the same filesystem.
I’ve been looking into Gitflow recently, it’s an interesting set of scripts to facilitate a successful git branching model which some of the people I work with rave about.
In the end I’ve decided I don’t like the tool or the model, though both are interesting.
One liner to grab a git log summarising what will change when you push teh next release.
For this to work you need to keep the deployed tag in VERSION.TXT
I’m used to how svn export works, and have used this in a number of release scripts.
Git doesn’t quite have an equivalent
You’ll need to have git and git-svn installed.
The code samples are run in bash on Linux.