Timeline for Commit at a logical checkpoint only, or also when you're at a stopping point?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 1, 2015 at 8:30 | comment | added | G.Rassovsky | Yes, I admit this is not a git-specific answer. In fact disregarding the tag I tried to give generic advice, but from what I could understand from the OP's "disconnect" statement, he was referring to actually 'merging to trunk' and not to personal repos... Might be wrong. | |
| Apr 30, 2015 at 17:01 | comment | added | WarrenT | These policies seem to be reasoned from the perspective of how should a team work together with a repository, what should the team members see, what you want people to push to a repository you may work with. But a person can commit to private repositories, on personal branches, and squash commits before pushing to a shared repo. Best practices in that private realm have different considerations which are left ignored and unmet by policies such as your answer. | |
| Apr 30, 2015 at 17:00 | comment | added | Idan Arye | -1: this advice is good for SVN, where a bad commit breaks the project for everyone. In Git you shouldn't concern yourself about poor commits - as long as you don't merge them to master(and friends) they shouldn't cause trouble to anyone. | |
| Apr 30, 2015 at 11:50 | history | edited | G.Rassovsky | CC BY-SA 3.0 | edited body |
| Apr 30, 2015 at 11:18 | history | answered | G.Rassovsky | CC BY-SA 3.0 |