A quick cribsheet of the GIT commands I do when starting new work on an existing project, 'cos I'm forgetful.

I'm not saying what I do is a good process, it probably doesn't properly follow any good GIT guidelines; but then it also doesn't seem to be completely wrong and it does seem to work.

I occasionally end up with various chunks of code which actually do stuff I find useful, or at least amusing. That's usually shortly before I realise something else the code should do. To avoid me having to remember my usual "good git practice" process, I'm writing it here. Yes, it means I'm doing branch based development rather than hacking straight onto master. Also yes, I'm not using formal Gitflow practices. It's my code, in my repos, and this seems to give me what I want.

So, first step, get my old pile of code:

~/projects/$ git clone /mnt/nas/git/coolproj
~/projects/$ cd coolproj
coolproj/$ mvn test # or equivalent for other languages

At this point I have the master branch of the project and proved that it at least works to some degree.

To avoid treading on my own toes, I'll make a new branch and start my new pile of hacking on there:

coolproj/$ git checkout -b add-cool-feature
coolproj/$ $EDIT # start preferred editor and get hacking
coolproj/$ mvn test # lets assume I've been good and written new tests
coolproj/$ mvn clean
coolproj/$ git add .
coolproj/$ git commit -am "useful message about what I've been doing"
coolproj/$ git push # Doh, this fails for the first push
coolproj/$ git push -u origin `git branch --show-current` # usually aliased to something like jfdipush
coolproj/$ git status

Hopefully that git status tells me everything is fine and I didn't forget anything. And that's my changes safely stowed away, after that I can repeat a simpler set of steps until I'm happy the new stuff works nicely:

coolproj/$ git pull # in case ghosts have been helping me
coolproj/$ $EDIT
coolproj/$ mvn test 
coolproj/$ git add . # assuming my .gitignore is good
coolproj/$ git commit -am "useful message about what I've been doing"
coolproj/$ git push
coolproj/$ git status

After a while I'll hopefully be happy with the resulting new code, then it's time to get back onto master and declare it the new "proper" version:

coolproj/$ git pull
coolproj/$ git push
coolproj/$ git status # check my branch is all stable and good
coolproj/$ git checkout master
coolproj/$ git pull
coolproj/$ git merge add-cool-feature
coolproj/$ git push
coolproj/$ git status

If that status comes back ok, I don't need that branch any more, time to throw it away:

coolproj/$ git branch -d add-cool-feature
coolproj/$ git push origin --delete add-cool-feature
coolproj/$ git fetch -p
coolproj/$ git status

I now have all my new stuff on master, if I'm feeling extra happy I may declare it time to bump the version number via a new git tag. For my own stuff I very rarely bother with versioing, as I'm the only one using it.

If I'm doing anything which other people may want to use or rely on, I'll try to stick as closely as possibly to SemVer (major.minor.patch), using git tags. Although by now I'm probably looking at Github or Gitlab repos, and I'll probably be using their tagging tools rather than the command line.

Lets assume I'm feeling tag-happy:

coolproj/$ git tag
<look at the list and ponder which version part needs bumping/>
coolproj/$ git tag -a A.B.C -m "Version A.B.C - did new stuff, yay!"
coolproj/$ git push origin --tags

Previous Post Next Post