How to commit correctly?

Question

git

It seems reasonable to make commits like this: I made some completed module / block / action, checked it - committed it. Well, or I think that I did, it doesn’t matter, some kind of completed logical iteration.
But when working on several computers, for example, at home and at work, it becomes necessary to push at an illogical (from the point of view of the code) moment. And there are commits like "worked on the laptop."
What is the right thing to do, how not to produce such bad commits or how to delete them later?

Answer 1

We make a temporary branch temp1 and push whatever we want there.
Then, when we finish cutting the feature, we switch back to master or dev and do
git merge --squash temp1
All changes will be transferred to master/dev, but will not be committed.
Now you can make a regular commit with a description of the feature, everything will be in one commit.
After all, we delete the temporary branch with the --force key. It is
better to name the temporary branch somehow more clearly than temp1, if you are not working alone. feat-super-duper.

Answer 2

Don't treat the Gita like a sacred cow. Nothing needs to be removed. Sent a crooked message - figs with him.
No need to write "worked on the laptop" . Write in the spirit of "Adding X to module Y (part 1)".

Answer 3

As an option - push into a temporary branch.
And then merge into the main feature branch and
git reset --mixed to the last normal commit. And remove the temporary. Then there will be no trace.
And if the office doesn’t mind, you can generally create a separate remote repository for these purposes
. Also, you can see how git stores stash’s, maybe you can copy-paste them

Answer 4

What is the right thing to do, how not to produce such bad commits or how to delete them later?

* push all bad and good commits into one branch
* when work on a feature is finished, do a git reset to a commit before our changes
* commit all our changes in the form of one (or several) commit(s)
* profit
There are a couple of nuances with this approach: it will be necessary to push the final commit with force (--force), if someone decides to merge an unfinished branch, then it will not bring anything good.

Answer 5

Make a commit with a description of what you did, what you didn't do, start the commit with the line "WIP: " (this is the standard abbreviation for "work in progress", many systems ignore commits with such a beginning of the description).
After you continue and make a logically completed commit, then rebase and remove this commit from the history (of course, if the branch allows it).

Answer 6

You synchronize the code using dropbox or something similar, you commit when you see fit.