何时提交并推送到工作的远程 git 存储库？

Question

My question is not related to an obvious coding problem but after 3 years of experience working on different projects and using Gitlab & Github. I am still not sure when to commit & push the code implemented so far to its original repository.

To be clear,

• shall we do a new push whenever we finish a certain task?

• Or maybe whenever we write a certain code and we are sure that it's not going to be changed?

• Or as usually I do at the end of a working day if the task does not finish yet (just to save the work remotely) as a [WIP] push!

• Or...

Is there any link or resource for similar thoughts?

Answer 1

Create a commit every time you accomplish something

Think about rock climbers. They climb up a vertical rock wall, every inch is a difficult battle. Every so often, they stop to hammer a spike into the rock and attach a rope. Why do they do this?

So they don't die if they lose their grip and fall.

There are many reasons to use source control, but this is one of the biggest ones that matters to the developer.

Each of us is often working on the hardest task we are capable of, which means the work is hard. When the work is hard we are likely to make mistakes, to suddenly find ourselves in strange territory and not know how to get back to safety. An extremely common scenario is to have difficulty creating a first working version of something, to finally accomplish it and demo it for your bosses, then accidentally break it when you go back to your desk to clean up the code or finish the task. I have seen people spend waste days trying to get back to the point they were at when they did the demo.

A commit is like a map marker you can teleport to from anywhere. No matter how lost you get, no matter how badly you break things, you can always go back to the way things were at that commit.

Commits are free. It costs nothing to create a commit. The rock climber only has 20 spikes in her bag. You have an infinite number ¹ , Commit early, commit often!!

Write decent commit messages so you can tell them apart: they are notes to yourself and your life might depend on them sooner than you think.

Here is a not-terrible example to illustrate how small are the things that count as "milestones":

1. got the form fields laid out right
2. added the submit button
3. stubbed validation hook for form submission
4. installed validation library and wired it into validation hook
5. defined custom validation rules for the address fields
6. wired up display of validation failures
7. fixed layout of fields after error messages messed it up
8. replaced validation library with the version they told me to use
...

If you are working on your own private branch -- which you should be -- commits are also secret things you can clean up later before anybody else sees them. If you are embarrassed that it took you 25 commits / 25 attempts / 25 steps to do something that is "easy," you can edit your commit history before you submit it for code review. Some places even require you to squash your history down when you're finished -- which is no reason to not create lots of commits while you are doing the work.

I usually create 25 - 50 commits per day. I spent a month working on a big feature and had 269 commits at the end. Nobody saw those. When I was finished, I squashed it all down to basically 1 commit. Nobody knows it took me ~300 tiny steps to climb that mountain. All they know is that I made it to the top and planted their silly flag, and that's all they care about. You are the person who gets hurt if you fall.

How often should you commit? How much of your own work are you willing to recreate from scratch the next time you make a mistake that you can't figure out? Are you so amazing at programming that you can sling code for weeks without any missteps, without any false starts, without having any ideas that failed to work out? Even if the answer is "yes, puny mortal, I am the god of programming,"? do you really gain anything from playing by those iron-man rules?

Your safety net is made up of commits. Don't skimp on materials.

---

^{1 It turns out there is a limit to the number of commits. According to this answer , you can have at most 1.4✕10 48 commits in one repository. That's plenty. And if you run out, you'll become famous: the first and only programmer to outgrow git.}

Answer 2

usually I do at the end of a working day if the task does not finish yet (just to save the work remotely) as a [WIP] push!

No need for that: you create a feature branch where you are the only one working on it, and you can commit/push at any time.
You will be able to rebase/reorder/squash commits later when you want to make a pull request to the target branch you want to contribute..