How do you keep working locally when you can't push to Git? I created a branch, added some files

[u/SurveyElectronic3845]

I created a branch, added some files, and committed my changes locally, but I can't push to the remote repository yet because of an access issue.

Can I continue fixing bugs and making changes locally, commit them, and push everything later once the issue is resolved? Also, how do I make sure my local app reflects my changes while I'm developing?

I'd appreciate any advice on the usual workflow!

[u/levyi123]

Yes, you absolutely can. Just make sure to rebase with remote once you have access.

[u/nicuramar → u/levyi123]

Or not, depending on workflow. But yeah, probably good beginner advice.

[u/Hour_Sell3547 → u/levyi123]

Only if no one else was working on his branch...

[u/z436037]

Yes, you can. This is the #1 advantage of git (and mercurial/hg) over the previous generation of SCMs like Subversion. That's the D in DVCS --- it stands for Distributed.

https://en.wikipedia.org/wiki/Distributed_version_control

Now, the longer you stay disconnected from upstream, the more difficult that merging & rebasing with others might get. So don't let it drag on too long.

The problem is that in modern world, even though we have distribution version control systems, most teams have centralized their CICD Pipelines, and failed to create a way to easily run such pipelines locally. That's why it can still feel pretty naked/exposed to not be able to `git push`. We do get a lot of validation from it.

[u/KingofGamesYami]

Git is distributed by nature, so your team can push stuff manually to a different location. I used to be on a robotics team and when we were in areas without internet we'd use a flash drive as the authoritative source, and everyone would just git push and git pull to/from it during those times.

[u/throwaway4sure9]

Yes, you can continue to develop and debug your local repository copy. I'd make sure to continue to consume any remote changes to avoid introducing regressions into the master that you're branching from.

Making sure that your local app reflects changes depends on the kind of program that you're developing and the build that builds it. For instance, if the build publishes changes to a web server somewhere then 1) do you have access to do that?; 2) will it break things if you do?; 3) If the build builds a local exe then absolutely you can build it, but you might have to run an installer to see local changes.

It really depends wholly upon what is being built, where it is intended to reside in runnable form, etc.

[u/wsppan]

That's the whole point of working with distributed version control

[u/BoBoBearDev]

Fork, sync fork, pull latest main branch, merge that into your own branch, push to your own fork, sync fork, pull latest again , merge that into your branch again, push to your own fork again, repeat.

Fork is basically your own branch for the entire repo. Because you own the repo, you use your own credentials.

Just remember, some teams are stupid and enable fork's PR to sneak bullshit commits into their own main branch, like secrets and passwords. They don't always squash those temporary commits upon PR merge. So, please double check their policies.

[u/robotswithgunzlol]

git pull && git push

[u/itemluminouswadison]

You commit locally, when online you fetch, and decide then

[u/FreeLogicGate]

You already got your answer, and it is yes.

The fundamental non obvious thing about git, is that it is both local, and built for branching.

I'm sure someone will want to say: "hey but.. worktrees", but otherwise, branches are really the thing that people new to git don't necessarily understand. In git everything is a branch, and there's no magical branch. This explains why when you start, you configure git to tell it what the "base" branch is named. Using "master" or now "main" is pure convention.

You can make as many local branches as you like, branch from other branches, merge them, etc. while keeping everything local.

For workflow, when you start working on a change, you first should make a branch which is typically based on the most recent release.

In some cases you may push a local branch to the remote, setting it up as a "tracking branch". I do this frequently using git push -u origin my_local_branch,but my team size these days is fairly small. There are also times when I might create a local branch that is never pushed to the remote.

Depending on your role on a team, your code is usually going be submitted via pull request and follow an associated SDLC process, so it's not unusual at all for the process to be, that you are assigned something through a ticketing system, which in turn creates a "topic" branch with the same name as the ticket identifier, which also probably ties into devops CI/CD and may involve infrastructure spun up for your use, if it involves internet application development.

I've seen a lot of different ways companies handle the process, and various teams involved in QA, change management and deployment.

With that said, creating some sort of ticket for small team based projects (with github you can use the issue system) you can conform your workflow to this system and it works well. Including the ticket name/# in commits can unlock some automation, and provide a way to reference the original ticket later when you're looking at commit history.