I Love git. After a year, I still can't decide how to break my commits up. Should I create a new commit with every level me of code, or every function or feature meaning (a few functions). What are your ideas?

Subscribing

📌

If it's a small task I commit when I'm finished, and if it's big, then when I suddenly get horrified by a thought of loosing what I wrote so far.

I'm going to be that annoying guy and say there's no real formula for it. When you say to yourself 'This. This is code I'm happy with' or 'This next idea may break things', it's usually a good indication of when to commit. The latter is definitely one to adopt early!

@linux-colonel I've started a few projects with high enthusiasm, only to begin losing steam midway because of deadlines. One of my biggest issues when working with git is that I try to make sure that each commit is clean and only does one thing but there have been instances where I ended up committing several changes all at once, at such a point everything I've done before start to feel like it's pointless since I have polluted an otherwise clean project.

What are your thoughts on feature branches? My initial approach was to keep a branch for setting up deployment and another a specific feature like login. And then I learned that apart from merging into develop/master we can rebase our feature branches from either develop/master, the implications of this is after rebasing feature branches their existence post merge is pointless. Should I keep these branches at all or merge then delete and recreate that branch again when needed?

Make your commits as atomic as possible. Every change that goes into a commit should relate one particular action. This way, reverting or cherry picking commits is extremely easy.

@vinaysshenoy this has been my approach until something creeps in because of an impending deadline.

@linux-colonel Agreed. Commits may be big or small, as long as the changes are documented. It's up to the developer to decide what counts as an acceptable "unit" for commit sizes. One may commit a couple lines or a whole set of files. If one does commit lots of files at a time, I've found one gets pretty good at writing commit messages, though!

@luminous-flux but wouldn't be better to stick to one way of doing things. So you always know what to expect from a commit.

@stalinkay on the rebase comment - Don't. Just don't. Rebasing is there if you need to fix an issue. It completely destroys your history. Learn to do merges well, and you should never need to rebase

@linux-colonel I use git pull --rebase to avoid having to merge other users commits and keeping my feature branches up to date with develop/master. I haven't seen bad side-effects of that please school me.

I branch features and commit functions/fixes. Has been working well for me so far.

I dont have issue with people commiting broken/in progress code, Assuming its branched for an in progress feature. But if i pull a master branch and its not functional, i will reset that head... --hard

Every commit should correspond to something that compiles, is definitely tangible progress towards your goal, and encompasses a single idea.

A new line of code does not warrant a commit, but a new class or feature (that you will use) does.

If you happen to need a one line fix, make a separate commit for it. Be verbose as fuck on the little one liners. It's okay to see "Bugfixes" in release notes, but your commits had better say a lot more than that.

Do not shoehorn things in together that you will not want to revert together.

@bitFlipper this is close to how I've been doing things.

@bitFlipper and possibly what I would put into a style guide.

@stalinkay you say rebase avoids merging in other changes. How so? If two devs touch the same file, one must merge. If they don't, the initial change will be lost.

Let me put it this way: what advantage does rebase give you over merge? To me, the branch/merge strategy leaves you with an exact representation of what happened during development. Rebasing will destroy that and make it look 'pretty', but does that help you a week/month/year down the line?

@linux-colonel say you have a master branch and you checkout a new branch based on master. At this point both your feature and master are the same. Now suppose somebody merges 2 PRs to master and you make 1 commit on the feature branch. Both your branches would have diverged at this point. Now imagine if you needed the changes on master you would have to merge master back into your feature branch creating a merge on top of your current feature commits. git pull --rebase origin master pulls in master branch changes into your feature and places your commits on top on what is currently in master without a merge commit. I hope I understand the logic correctly. I'm no guru at this still learning. Please check this link https://medium.freecodecamp.com/git...

@linux-colonel check this one instead https://coderwall.com/p/7aymfa/...

@linux-colonel I think this is the one https://derekgourlay.com/blog/...

@stalinkay I can't stop you doing what you want to, but the articles you shared both confirm that rebase destroys your history. Having worked in a distributed team of over 100 devs, I can safely say - history is king

I wish I could find the SO thread that explained my point better than I can...

One per day with comment: "daily commit"

I'm fairly new to Git but for me, I have a branch to myself (and soon one for my colleague) which I do all work on and then I merge to master with each major chunk, making sure that it builds an all unit tests compile.

I find that actually it helps force me to fix things because if I want to work on another feature I have to fix any problems with the last thing I was working on first.

@Kaito23 this sounds like very bad practice

I tend to have a 'dev' branch, from which I branch off my features, and merge them back to. I only merge dev to master when I'm ready to release my software. Master then only contains merges and tags. I have no direct commits to master. I'm always sure that the code committed to master is correct and works. Probably not needed for personal projects, but it's a methodology I learned from enterprise development, so I feel it's a good practise to follow

I actually tied `git commit * -m "changes" && git push origin master` to my return key. That way I can always make sure master is up to date.

@linux-colonel I agree completely on this. I never work on the master/dev branch those contain merges created through PRs.

@linux-colonel I don't do git pull --rebase on master/dev but on a feature branch that I want to keep up to date with master/dev depending on the situation.

So the history on master/dev is maintained.

@Kaito23 I strongly believe that this could result in a situation where you lose an entire days work in the event that something happens to your data.

@Kaito23 i actually loled