4 ms·
I dont make commits that large or complex, and if you were to ask my opinion I would say you shouldn't be. I don't write 3 pages the save my word document, I sa
by jenius 15y ago
I dont make commits that large or complex, and if you were to ask my opinion I would say you shouldn't be. I don't write 3 pages the save my word document, I save almost every couple sentences. This makes life easier for me as far as keeping track of things.
Of course to each his own, and everyone has their own style - I'm trying to suggest a best approach for learning developers. Would you suggest that learning devs use gitx? If so, I'd love to see an article about it!
- paxswill 15y agoI agree that ideally commits are atomic, but I'm not as disciplined as I should be and sometimes I end up with changes that really should be more than one commit. I can split them up from within git's CLI with `git add -p`, but this can be cumbersome. GitX lets me quickly choose which chunks and/or lines I want to commit, and exactly what is staged. There's also a commit message box right there, so I usually end up committing right there. What I do agree wholeheartedly with is using the Git CLI for tree operations. Knowing what you're doing with `git pull`, or knowing when to rebase as opposed to a merge is incredibly useful when using git, and ultimately makes your usage of git more effective. In short, I advocate using some sort of interface (GitX, fugitive.vim) for staging, and possible committing, but the git CLI should be used for almost everything else (except submodules, which seem to require an unholy mix of git and normal file operations).
- jenius 15y agoFair enough. I'm going to check out the two you mentioned and give them a shot when staging/committing, and see how I like it. I assume they will slow me down since I commit very atomically almost automatically, but it's more than worth trying. Thanks for the input!