Timeline for Commit at a logical checkpoint only, or also when you're at a stopping point?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 4, 2015 at 14:50 | comment | added | Krystian | @coredump I guess it depends on your work environment. for me the whole purpose of git and other distributed VSes is to push those commits. Local history is something that most decent IDEs offer out of the box. | |
| Apr 30, 2015 at 20:37 | vote | accept | Thomas Stringer | ||
| Apr 30, 2015 at 17:05 | history | edited | coredump | CC BY-SA 3.0 | added 9 characters in body |
| Apr 30, 2015 at 16:43 | history | edited | coredump | CC BY-SA 3.0 | deleted 13 characters in body |
| Apr 30, 2015 at 16:37 | history | edited | coredump | CC BY-SA 3.0 | deleted 13 characters in body |
| Apr 30, 2015 at 16:25 | history | edited | coredump | CC BY-SA 3.0 | added 658 characters in body |
| Apr 30, 2015 at 16:00 | history | edited | coredump | CC BY-SA 3.0 | added 2 characters in body |
| Apr 30, 2015 at 15:41 | comment | added | Brendan Long | I think this answer should add a little more detail about amending commits. It's the right solution, and you mention it, but I think it's not prominent enough so people who don't already know about amending aren't noticing it. | |
| Apr 30, 2015 at 15:31 | comment | added | coredump | @ThomasStringer I agree that there is little benefits. I like stashing because commands are very short to type, and because it looks more like WIP than a normal commit. | |
| Apr 30, 2015 at 15:18 | comment | added | Thomas Stringer | I don't see how stashing would be of help here. Sure that would give me a clean working directory, but only by stashing and reverting the working dir to last commit, no? I like the rest of the answer, though! | |
| Apr 30, 2015 at 14:57 | comment | added | coredump | @Krystian This does not matter, since everything you do on your own local copy is, well, local (I assume you don't share your computer with someone else). You could even commit on master, as long as you don't push in-progress work. That's how I work with git-svn, for example (I also use local branches). | |
| Apr 30, 2015 at 14:50 | comment | added | Krystian | It also depends on your team's git strategy [if you work with a team]. You didn't mention how you use git and if you are the only person working on the project.Are you going to commit to master branch? Or do you have your own branch you work on? If you are on a branch with other people, I would say - keep it to yourself. Commit when you finish and push to your own branch. Then before pushing to master - squash the WIP commits. | |
| Apr 30, 2015 at 14:16 | comment | added | coredump | @Bergi Commits should be atomic units of change, and for the benefits of other people who will read the log (which includes future 'you'), it is sometime better to edit intermediate commits, with an interactive rebase, for example. I am not saying every push should be one big commit; on the contrary, it is easier to have a chain of (as small as possible) commits that have a clear purpose. | |
| Apr 30, 2015 at 14:11 | comment | added | Bergi | You say one shouldn't push such commits. Do you mean they should not become part of the (pushed) history, but be temporary only? | |
| Apr 30, 2015 at 14:04 | history | edited | coredump | CC BY-SA 3.0 | added 218 characters in body |
| Apr 30, 2015 at 13:43 | comment | added | seldon | If the task is too big to be finished in the time slot you have, you can make a new branch and do all the dirty stuff there, merging it after all is completed. Sounds good to me. | |
| Apr 30, 2015 at 9:35 | comment | added | sleske | If you have changes that you do not want to push without rebasing/amending them, you can start your commit message with "WIP" (git -m "WIP: dirty test code"), and activate the pre-push hook under .git/hooks/pre-push. Then git will refuse to push as long as the commit exists. | |
| Apr 30, 2015 at 8:57 | history | answered | coredump | CC BY-SA 3.0 |