6

This question already has an answer here:

TL:DR; Shall I start comitting regularly small pieces of code in new projects? Even if I'm start from scratch and don't have any experience in what I'm using (framework, programming language, w/e)?

Whenever I've learned something new for myself I did not have commited anything in an early stage. For several reason: Basically beacuse I've no idea what I'm doing and don't know any best practices yet etc. So I just start and try things and rewrite them for like 100 times (at least it always feels like that).

Yet I've got a new job and I'm starting a new complete project in AngularJS with Spring Boot backend. I'm mainly working on the frontend. I'm pretty new to Angular and JS in general. At this moment I'm the only one commiting to the project. The initial commit was like yo jhipster (this set's up a complete app skeleton that is ready to run) and some custom database mappings.

My first commit was like

Implemented controller X 

Sorry for large comment I've just started with Angular. [...]

Since I don't have the time to learn things in a sample project and there is a very short deadline for a first presentation I feel like it's better to have some bigger commits. I'll try to keep commits at least related to one topic. Like

Integrated template X into project

Replaced this with that and [...]

Anyway - this commit will be huge. Unlikely that someone will check the whole diff.

I'm working on a seperate local branch themeIntegration. I'll do there smaller commits that are actually just to have some commits where I can fallback if something goes absolutely wrong or I just recognize I've did probably something wrong I'll change a lot now. I'll squash merge it into my develop branch later.

marked as duplicate by gnat, user40980, user22815, Kilian Foth, Michael Kohne Jun 11 '15 at 12:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • @gnat did you read my question? I don't feel my question answered there :/ – Brettetete Jun 8 '15 at 22:00
  • At a previous employer, we adopted Mecurial (an alternative to Git I prefer) and we used it like a glorified undo stack, with comments explaining each branch and level. One colleague made a commit an automated part of his build script. It was great. – Matthew Reddington Jun 9 '15 at 14:45
  • 1
    The purpose of committing is not to make you feel good, or to demonstrate how able you are. It is to insulate you from the effects of inevitable process failures that occur on digital assets. There is no reason not to commit something except that it has no value whatsoever. (But if has no value at all, why did you spend time on it?) – Kilian Foth Jun 10 '15 at 12:17
  • Side note: I think "Sorry for large comment I've just started with Angular." is something that should never be in a commit message. – user253751 Dec 25 '16 at 23:48
19

You should commit often.

But @durron597! I'm a beginner programmer! I don't trust my commits!

This is why you are committing on a separate branch!

You can even have many branches that you're committing to for your own use, for different fits and starts and experiments and whatnot.

Don't worry about big fancy commit messages. The only commit messages that really matter are the ones that occur when you finally attempt to merge your changes into trunk. At that time, go through your whole list of smaller commit messages and aggregate them into something someone else will read. In the meantime, your commit messages are only for you, and having a big commit history can only help you to track down problems if you make a mistake.

  • 1
    +1 exactly what I was going to write. It's actually very common for me to commit with a message like "stash commit" because I don't want to lose some work, but I want that work to be bound to the branch I'm on instead of just git stashed. – Ixrec Jun 8 '15 at 22:09
  • 1
    @Brettetete Sure, why not? – durron597 Jun 8 '15 at 22:12
  • 1
    @Brettetete People don't look at commit logs unless they have a reason to do so. Your mess is not really a mess at all. – durron597 Jun 8 '15 at 22:20
  • 4
    The only history worth keeping "clean" is the history on master. This is why you rebase/squash/whatever before merging, depending on what you want that clean history to look like. Part of the reason the feature branch workflow is such a big deal is that it removes most of the legitimate reasons for not committing frequently; you don't think about history cleanliness until you're done working on the actual feature and you're ready to do the cleanup and merging. – Ixrec Jun 8 '15 at 22:23
  • 3
    Obligatory xkcd: xkcd.com/1296 – Ixrec Jun 8 '15 at 22:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.