Learning DVCS Workflow - 3
Recently for work I wrote out some steps to work through to get from a Subverison (SVN) repository containing large files, into a git repository using git Large File Storage (LFS) to house the big files separately.
Recently for work I wrote out some steps to work through to get from a Subverison (SVN) repository containing large files, into a git repository using git Large File Storage (LFS) to house the big files separately.
I hacked on my web site project this Easter long-weekend, and learnt how to split the existing repository into separate projects, and then glue it back together again.
I also learnt about Git Large File Storage (LFS), how to set it up, and how to migrate certain file types to use this for more efficient handling of binary files.
Having covered what pass is, why I'm using it, and the required supporting tools gnupg, git, ssh and a private git remote, it's time to go over how to put the system together.
Setting it all up on a Unix computer is fairly straight-forward. Getting it onto an Android is a bit different. So in this post I'll cover how the pieces of the system fit together, and then walk through setting it up on Unix.
Synchronising your local password-store git repository with your remote store is done a bit differently depending if this is the first time you're setting up the remote, or if you already have a remote and you wish to merge it into your new local. I'll cover that too.
I spent some spare hours on the week-end playing with Pass, importing my KeePassX database into password-store and synchronising it to a GitLab private repository.
It's a little tricky to get it set up, with a few moving parts, so I'm still experimenting. Here's what I've figured out so far.
Tonight I learned a basic git trick that was not immediately obvious to me, but should have been, I guess.
I've been switching my Spacemacs back to the master branch to try trouble-shoot a performance issue I'm having on the Macintosh where it just hangs occasionally. My master is tracking to Spacemacs master which is still at 0.200.13. I haven't touched it in over a year, and there are some things that I wanted from my develop
branch.
I want to merge in the latest version of those few files, but not everything on the branch, so a merge is not the right operation.
If you take look at the revision history for some of my projects on GitHub, you'll see that I have a fairly messy track-record!
A few times I have successfully used Magit's ability to interactively stage/unstage Hunks or parts of Hunks, to make my commits a bit more clean and sensible, but not always.
The real problem is: I haven't been using Branches. It's because I haven't studied how to use them effectively, and in the past they've been scary.
But for the future, and especially for my dotfiles, I'd like to be able to read through the commits and make sense of them after. Also I'd like to be sure when I'm committing that I don't make any unplanned master changes and break things.
I also tend to work by myself on these projects, but I'll often go on a tangent, or start a blog post and then put off finishing it while another, different idea is developed and maybe even published first. Ideally I should be able to track these things separately.
So I need to learn: how to do revision control workflow with branches, properly.