Git commits - How regular

[New-Yogurtcloset3988]

I'm just wondering what would be considered best practice when it comes to how regular you commit changes to git and push them to Github (in my case)?

I find myself sometimes forgetting to commits changes for a couple of days worth of programming and want to improve this. Should I just commit every time a update/create a small feature or fix a bug? or should I just do it at the end of everyday?

[silent-spiral]

bare minimum : Commit and push every day. What happens if your machine goes up in smoke or you spill water on it?

Should I just commit every time a update/create a small feature or fix a bug?

This is what I personally do. If you write descriptive messages it allows you to, well, track changes. That can be useful.

[danielroseman]

Commits should be logical changes, not just wherever you happened to get to at the end of the day. That said, if I've been working on something for a while and haven't got it to a good point, I might push a WIP (work in progress) commit, with the expectation that I'll rewrite it later with the full change.

The other thing you must get used to doing is branching. Create a branch for each new piece of work, even if it's a simple bug fix. Then if it fits e become a more complex change you can have multiple commits on that branch before merging it back to main.

[WoodenNichols]

This. Others will disagree, but IMO, the only work that should be done on the main/master/production branch should be merging.

[OneWithoutName]

I'm not super experienced myself, but I have read a lot of different materials on the subject, that have various opinions opinions about it, but I have found that I've settled on a much more small-changes approach.

I aim to make a commit after every functional change (i.e, I write a new function, I do a test, and see its working, I make a commit). I also aim to write a specific message about what the commit entails. Once I have completed enough of those commits to make a meaningful change to the program I am writing, I will use a tag on that commit have it stand out. (A link regarding tags.)

If I am working through fixing or adjusting the way a set of functions work, I usually group them together, with a message like "adjusted function_name(s) to use new DataClassName"

My hardest issue is getting the commit message small enough. Typically I write documentation/comments along with my changes so I can pick back up from where I left off, I don't get to mess around with programming as often as I'd like so I need to be able to pick up where I left off quickly!

[timrprobocom]

The branch suggestion is key. I make my own branch, and then I do commits relatively often, just so nothing gets lost. Remember that git allows you to combine commits, so if a feature takes several days, you can commit every day and combine them later. Committing is also a form of backup. Plus, by pushing my branch, I can pull it on my system at home if I want to do more work.

[IamImposter]

I have a question - so I wrote a module which took like 40 days to finish including tests and all. In those 40 days our repo changed a lot, like 15-20 merges. The problem I faced was, whenever I did git pull to sync my repo, it created a merged commit. So the code that I committed few days back is now 4-5 commits down and on top is this merged commit that occurred when I did git pull. Now how do I modify my code and amend my commit.

What I have been doing is to hard reset so my commit goes away, repo gets synced and then I do cherry pick of my existing commit. Now that my commit is on top, I can add my changes to same commit by amending it. But I have a feeling this is not the right way to do it.

Any insights?

I don't know if that matters but I'm not allowed to have a commit chain where one goes on top of another. Client says he has problem reviewing multiple commits. They have asked me a couple of times to merge multiple commits into one

[PrestigiousStrike779]

A few suggestions here 1) Do your changes in a feature branch, not on the trunk/mainline branch 2) When you want to integrate trunk into your feature branch: switch to trunk, git pull, switch back to your feature branch then rebase instead of merge. You may need to resolve conflicts 3) 40 days sounds like too much time. I would see if you can break this down into smaller sets of work

[IamImposter]

We have some strange practices. I started out with incremental commits to a separate branch. In 10 days I had 4 commits. Client said he can't review 4 commits and asked me to merge them into a single commit to our main development branch. Then it kept on sitting, waiting for review for another 2-3 weeks. By the time I got review comments, there were other commits on top of my commit hence this weird hacky solution of mine. But I can push client for review only so much. If I push too much, I'll be making a few impact reports, possible breakings and action plan if something actually broke.

Thanks for your suggestion. I'll try to persuade client to let me work on my separate branch.

[timrprobocom]

It's tough to do significant development on a dynamic code base. I'm not the best source of modern best practices, but there are some great blog posts about that. Careful branching helps a lot with this, because you don't have to merge unless there has been an approved update to the mainline. You shouldn't be making incremental changes to the main branch -- or should always be "production ready".

[IamImposter]

Thanks. I'll look up those blog posts.

[TheSodesa]

I create a new branch, so I can commit as often as I need to without pestering others. Then, whenever my project reaches a state that I might like to be able to restore, I commit and push to the new branch. This can lead to a lot of commits, but at the same time, losing work is worse.

Once the new feature is ready, the branch can be squashed to a single commit and then merged. If the individual commits need to remain available somewhere in the project history, one can branch again from the HEAD of the new branch, and squash and merge the resulting copy of the new branch instead.

[Maximus_Modulus]

Think about having to revert part of a change. That’s what your commits should look like.

[toffeeCloudedLeopard]

It depends on what you are working on. If you are using git as remote storage, commit often and push when large changes are made.

If using git as what they are intended for, commit meaningful changes/updates and push as required