Wow that's an awesome idea too aka to create local branches on each machine, and then switch over the master branch to pull them in.
I like videos first, and then documentation.
It would really help me out since I'd love to try to figure this kind of thing out, since I am pretty close to just using rsync for my Git notes going forward, but needed that kind of convincing otherwise.
> Not sure if it counts as off-topic for this thread, but does everyone use Git to manage their Org docs and notes?
>
> I ask because of Greg's previous post.
>
> I've noticed that some times after git merge events across a few machines (ex: I forgot I had already pushed notes for my private notes on one machine,
> and had to merge the results from another machine), I'll get weird "HEAD" and "END" statements inserted by Git.
>
> Also, combined with some tasks duplicating as a result was annoying.
>
> Was debating if this is just something I'd have to deal with, or if there might be a better versioning workflow (ex: just using rsync, etc)
>
> Would be curious on everyone's thoughts.
>
> ~ Sam
>
I use git as the master and then checkout to whatever machine I'm working
on. I tend to have at least 3 different machines I'm working on (home
Linux, work Linux and Macbook).
On each machine, I will checkout from master and then create a 'local'
branch where I make any local changes. When I'm finished working
locally, I will commit to the local branch, switch to the master branch,
do a pull. If no changes are pulled, then I will merge in the local
branch and push up to the master repository. If changes are pulled, then
I will make a decision whether to use rebase to add those changes to my
local branch or just merge. Deciding on which depends on the types of
things changed, size of what has changed etc.
I find rebasing and merging is often the best approach to keeping commit
logs fairly clean and linear. However, that will depend on what is being
changed and the amount of changes. Frequent pulling and either merging
and rebasing is useful.
Creating new branches (both just locally and within the master
repository) is a very lightweight operation. I use lots of branches and
will regularly go back through and get rid of old branches when no
longer needed (i.e. changes in the branch have been merged into master
or the branch topic is no longer relevant/needed etc). Understanding the
difference between a rebase and a fast-forward merge is important.
Likewise, using branches effectively is critical. My master branch tends
to be quite clean - I almost never make changes directly in the master
branch. Everything happens in another branch and later merged into the
master when ready.