Git keep some local changes clean, but don't push them
I am working on a development branch on my computer. I made a lot of changes that I don't want to push, but I want to keep them. I did to change the behavior of the translator in my project and I would like to test it a little longer before pushing it and deploying to production. But I would like to continue working on development or any other industries and be able to apply these changes.
There are ideas that I came up with:
-
Keep all of these files (not git-add them) and only commit the files that I really want to commit. But this solution makes my "git status" very messy (a lot of modified files) and I believe it will generate errors and commit the wrong files.
-
Git save "Translation" and apply it whenever I want to use it. But I will have the same issue with messy git status where I have to choose which of my files I want to commit or not.
-
Create a new branch with my new feature on it, but as soon as I merge it with my working branch I will do the merge as the same time
Do you know any other workflow to save changelog across multiple files and apply / remove abstract changes?
source to share
Something like git-flow or gitlab-flow works very well.
From what I've read, I can conclude that your project has 2 modules and you are modifying both of them.
One module is stable, but you modified it anyway and want to test your changes more thoroughly, and another is work.
I would use your third option, but merge your work branch into a new feature branch.
Or, if you want to separate your modifications from the "stable" module, you can keep them in a separate branch.
That is, you get 3 branches:
- Your work on a "unstable" module, a "stable" module without your last change;
- your modifications to the "stable" module;
- merge of the two above
Branching in git is cheap and easy, you can create any number of branches.
source to share
Save your local work-in-progress on a separate branch and push it.
- This will allow you to commit the commits properly, rather than committing huge monsters at the end.
- This will allow you to have a copy of your code on the server so that in the event of a disk failure or something similar, you don't lose your work.
- This will allow others to see your code and preview it before deploying to production.
Deployment usually comes from a single branch. Unless you merge your changes into this branch (although you need to check it in your place), you are safe.
source to share
I would suggest a different idea.
-
Create other commits
-
Push only specific commits for mastery
-
Push another commit when you need to keep your git status from being messy. (
There won't be much tracked files in git because files are already committed
)
The procedure is already explained here:
How can I push a specific commit to the remote and not the previous commits?
source to share
Do the third option, create a new branch for your function.
You don't need to merge it into development until you're ready - instead of changing it, go into a function when you want to test.
- To work with clean development code: check development.
- To work with the new translator code: check the function and merge the latest changes from development.
- When the function is complete: the merge goes into the function for the last time (if not already updated), then check out the design and merge function in it.
source to share