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.
A quick note about my git setup
My "remote" repo is on a local NAS box, mounted as a share on any dev/deploy boxes. So no SSH or HTTPs, but I'm still doing "proper" git style by having local and remote repos and push/pulling between them.
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
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
And that's me all done. Made a branch, did a bunch of work, tested it, merged it back, tidied up, bumped the version number. Time for beer 🍺