Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Possible drawbacks for having duplicate local sources of the project tracking the same Git remote
Context
I have started working on an Angular upgrade for a medium-sized project (from v. 10 to v. 15) and this is a rather long activity that is interrupted by other changes that need to be performed on the same project.
I have created another branch for the upgrade, but switching back to another branch takes a lot of time (npm install is very slow and the first npm start is the same) since branches use different node versions (I am switching these using nvm on Windows).
Possible mitigation
I am thinking of creating a local copy of the project, that tracks the same remote and work separately in the upgrade branch. Doing so requires being more careful (e.g. syncing changes done in the main branch).
Shortly put, I want to avoid making changes to the upgrade branch node_modules folder (as much as possible) until the upgrade is done.
Are there any other drawbacks to doing the local copy? Or is there any other solution to avoid wasting a lot of time switching back and forth from the upgrade branch?
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Alexei | (no comment) | Jun 29, 2023 at 19:46 |
This is definitely an intended use case of Git.
You will need to make sure your .gitignore files don't include any artifacts of your build environment. GitHub has a canonical set of .gitignore files here.
Be sure that all completed work actually makes it to your remote. (Use git push rigorously.) Consider suffixing the names of your feature branches with the version number they apply to.
If you slip up on these, then you will see an error on git checkout claiming that your branch doesn't exist, or you will end up checking out old code. But these are just the situations that would happen to another developer collaborating with you on the same project: they're all recoverable, at worst by recreating your environment.
0 comment threads
You want git worktree: https://git-scm.com/docs/git-worktree.
The idea is that you can have multiple branches of the same repository checked out to different directories, but they're still the "same" repository locally. I've used this technique precisely to avoid having to re-download node_modules when switching branches, among other related problems.
The main disadvantage to git worktree is that you cannot have the same branch checked out in multiple directories. That restriction is sensible, as it would be hard to sync the changes between the directories otherwise, but it's occasionally annoying. To work around this annoyance, I'll create a local branch like fake-branch that tracks main, develop, etc. (whatever the main branch is) and use fake-branch as the "resting" branch for my secondary directory. That way, if I accidentally switch to the main branch in my "normal" directory, I don't get an error.
0 comment threads
1 comment thread