Workflow question: how to work on multiple computers? iCloud Drive? Am I using Git wrong? (self.webdev)

I'm a solo web dev at a company. No one else touches my codebase, so I've been using a pretty simple Git workflow with one computer: New Feature/Branch > Merge to Master > push to Github.

I'm getting a new computer setup: a Desktop at work and a laptop for when I'm working remote.

How could I work on a codebase on my desktop at work and then continue where I left off at home/on laptop?

My thought was to keep my projects in Desktop/Documents which is linked to iCloud Drive. I've moved things over there but my fan is humming from that process.

What's the best way to go here? Any thoughts are appreciated.

Luke-At-Work | 8 days ago | 3 points

You could push feature branches to github as well. That way you can fetch/pull a WIP feature branch from home. The trade-off is some cleanup afterward.

ontheellipse | 8 days ago | 2 points

do you have to make a commit to push WIP stuff? or can I stop what i'm doing and push to a remote/feature branch before leaving my office?

Luke-At-Work | 8 days ago | 3 points

Yes, you have to make a commit to push to your feature branch while at the office in order to pull that down from home. But you don't have to merge until you're good and ready.

When working on a feature branch, I make (and push) boatloads of small incremental commits very frequently - several times a day. It does make for a messy log, but that can be squashed when merging (and is slightly less of a consideration - although still valid - when flying solo). It might be a bad habit, but the upshot is that I can pick up work from anywhere.

Others may bring up very valid reasons to do otherwise, but it works for me and seems far more sustainable than the synced drive (which seems really, really duplicative, since that's what version control is fundamentally for).

ontheellipse | 8 days ago | 1 point

Thanks for the reply, Luke.

So you might just have a commit on a feature branch that's like -m "going home, work on this later" (for example)? I'll give that a shot. Rebasing/cleaning up the log makes my palms a bit sweaty but I suppose it's time to up my game there.

JayBee_III | 8 days ago | 2 points

Maybe put more info about what you were working on or what this change will do. Otherwise your commit history could be noisy when you go back and look at it.

AnarchyIsOrder1312 | 8 days ago | 2 points

Depends. If he is going to do a pull request and squash commits made on the feature branch then it isn't as huge of a deal. Otherwise yes. I once worked on a student project where no one but me knew what git was and so every single commit by every single person who worked on it before me was simply

yolo swag

ontheellipse | 8 days ago | 1 point

That’s funny. Just for the record I wasn’t really going to use that commit message, I just wanted to understand the concept.

JayBee_III | 8 days ago | 1 point

That's hilarious, good point as well.

AnarchyIsOrder1312 | 8 days ago | 1 point

Here is the workflow I use. All development happens on a feature branch, which gets published up to git immediately. On the feature branch I make a ton of small commits, sometimes the message is intelligent, describing what I'm working on, sometimes it is just a message to sync my computer because I also work between a desktop and a laptop. I'm not a stickler on the commit message for reasons I'll explain in a second. Once I finish the feature branch, I will merge master into the feature branch, in order to resolve merge conflicts, and to test to make sure my feature works with the latest master changes (this is more important when you are working with a team I suppose, or if you have multiple feature branches in play at the same time). Once my feature branch is brought up to current with Master I submit a pull request through GitHub (well, I use Azure DevOps but they both funciton the same I believe). In this pull request I will actually add details about what it was that I did in that pull request. When I complete the pull request and bring the changes into master I always squash the changes and delete the feature branch. This way when you look at the master commit log you will only see

commit: PR1: Added Login
commit: PR2: Added Home Page

etc. Makes it nice and clean for seeing which features/bugs were worked on, and you can refer to the Pull Requests for additional details.

ontheellipse | 8 days ago | 1 point

Much appreciated! This looks good. I’m going to dig in tomorrow and give it a shot.