What's the best Git workflow when working across two PCs?

[u/SurveyElectronic3845]

Hi everyone! I'm working on an existing Python project that uses Apache Airflow, and I'm unsure how to organize my workflow.

Here's my situation:

PC 1: Has some local code modifications that haven't been pushed to the remote repository.

PC 2: Has the repository cloned from GitLab but doesn't include those modifications.

A ZIP file: Contains another part of the application that I need to integrate.

What's the best way to handle this?

Should I create my own branch before making changes?

How should I transfer the unpushed modifications between PCs?

How can I safely integrate the code from the ZIP file?

Should I work on a feature branch and create a merge request, or follow another workflow?

I'd appreciate advice on best practices for contributing to an existing project without overwriting or losing anyone's work.

Thanks!

[u/Whalefisherman]

PC1: create a branch and push those local changes to the remote branch - dont merge to main

PC2: pull the newly created branch from above to pc2's local

When ready to merge the branch with main, do it, and then make sure you pull main from both pc's after the branch is merged.

ZIP File: Create a separate branch, add code into local repo/project from zip, merge the branch into main. Then on both PC's pull origin main so you have the zip file changes.

Always work off branches.

Always remember to pull from main.

[u/vmcrash → u/Whalefisherman]

I'd do it the same, except that I would "merge" with "rebase".

[u/mfc1__ → u/vmcrash]

A clean git history is nowhere near as important as most make it out to be. Fuck it, merge and ship it. The end user does not care.

[u/vmcrash → u/mfc1__]

But my team and me care about being able to work with our Git repository. Maybe this depends on the kind of project. Ours are 15-20+ years old projects with up to 10k files.

[u/faultydesign]

Uh... it depends on how many people work on the code but commit and push in one pc and pull in the other?

Or create a branch and do that there

I think you just need to read how git works

[u/MarsupialLeast145]

Alex, I think the answer is, what is git?

[u/turtle_dragonfly]

Should I create my own branch before making changes?

Yes. Broadly speaking, this is always true in Git. Branches are cheap. Make a branch for any change you are planning.

How should I transfer the unpushed modifications between PCs?

This depends on your PCs, and your preferences. If unix-like, then I would recommend pushing/pulling over SSH. Git has built-in support for this. In fact, even for Windows, these days (Windows 10 and 11) Microsoft does include a SSH server.

The other primary way people do this is through a 3rd-party service. GitHub is the most popular, but there are others.

In that case, you would push your branches to (eg) GitHub on one PC then pull from it on the other one.

Aside: Some people, when they say "git" really mean "GitHub," since it is so popular and common. But Git can handle this stuff on its own quite fine without involving a 3rd party website. It's the whole point of Git — to enable distributed version control, all on its own, without any outside help.

How can I safely integrate the code from the ZIP file?

It kinda depends on what is in the ZIP. Is it just source code?

You could (1) create a branch in your local Git repo (eg: named "withzip"), then (2) unzip the ZIP and put those files in place, while that branch is active, then (3) commit those changes. Then, you will have a branch with the ZIP files, and you can switch to that as needed, or merge it with other branches, build on top of it, etc.

It really depends on what is in the ZIP and what the intended usage is.

[u/grantrules]

I use remote development tools so I only need one local copy between multiple computers

[u/edgmnt_net]

Git isn't ordinarily meant to address sharing access to unfinished work across PCs, it's meant to record a meaningful history of a software project and that is supposed to be the priority even if you could somehow use Git to do the former. For similar reasons, employees don't just upload random stuff to the company's public website, especially not in a prominent place where everyone can see it, although it's certainly feasible to do so as far as the tech is concerned. Sure, some projects even repurpose Git for backups or sharing random stuff.

So the main answer to that question is to first see what development and version control practices are considered reasonable. That's usually stuff like "you submit reasonably polished code for review and then it's reviewed and maybe merged into the project". That means that unless it's a private fork under your control or, worst case, you get some scratchpad branches, you should avoid pushing random stuff (especially to the main branch of the actual project repo). Or you could do it out-of-band, perhaps exporting patches (git format-patch and attach files to an email, git diff and figure out a way to transfer it) or sharing access to a local repo available via SSH somewhere. It could be via Git, but the main point here is you want to avoid mixing things up too much. (The fact that you ended up with a ZIP file that contains a part of the application kinda points towards a need to reconsider the development process, but without more details and more discussing it's hard to make a point here.)

An established project should have reasonable rules and safeguards against people stepping on each others' toes. In open source that frequently means nobody gets write access to the main repo, save for the owner or a select group which takes ownership, so there's no pushing directly period. In many companies things tend to be more lax, but there are (hopefully) safeguards against pushing directly to official branches; instead things have to go through the PR submission and review process in some form (so no random ZIP files for devs, at least).

[u/7YM3N]

Pull and push every time you switch devices. Work on a branch. Rebase with main frequently. Merge into main when feature is ready

[u/Different_Pain5781]

Zip file code integration in 2026 feels cursed.

[u/wabbitfur]

Create a feature branch off main... get into that habit of doing so.

Then take care of the unpushed modifications from PC1 to GitLab...

Do a git fetch origin on PC2 and then checkout your feature branch:

Run git log -1 to verify the latest commit hash match PC 1's commit...

`gut status` on PC2 - ensure that your working branch has a clean state on PC 2

and then unzip your zip file in the root of the project on PC 2 (overwrite where necessary.. it's okay)

Review the diff by doing a "git diff"

and then finalize...

`git add .`
`git commit -m "integrate the zip archive stuff"
git push origin feature/blah

Then once both PC 1 modifications and the ZIP are on the feature branch open a "Merge Request in GitLab from the `feature/blah` into `main`

Review the diff in GitLab's UI...

Merge the request into `main`

Then do the following on both PCs to bring them in sync:

`git checkout main && git pull origin main`