6

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.

Brettetete
  • 299
  • 3
  • 10
  • @gnat did you read my question? I don't feel my question answered there :/ – Brettetete Jun 08 '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 09 '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

1 Answers1

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.

Community
  • 1
durron597
  • 7,590
  • 9
  • 37
  • 67
  • 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 stash`ed. – Ixrec Jun 08 '15 at 22:09
  • `You can even have many branches that you're committing to for your own use` - Shall I push the branch so one can follow my *trashy* commits if he really wants do find an answer? – Brettetete Jun 08 '15 at 22:11
  • 1
    @Brettetete Sure, why not? – durron597 Jun 08 '15 at 22:12
  • @durron597 hm probably since I don't want to show my mess between "regular" commits to anyone. And won't this become a huge mess with the time? – Brettetete Jun 08 '15 at 22:17
  • 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 08 '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 08 '15 at 22:23
  • 3
    Obligatory xkcd: https://xkcd.com/1296/ – Ixrec Jun 08 '15 at 22:25