You don't have to look through too many commit histories on GitHub to see people are pretty terrible about making commits.
Now I'm not going to ...
For further actions, you may consider blocking this person and/or reporting abuse
Learn to love $git rebase -i
An interactive rebase is brilliant if you haven't pushed your work to a remote yet, because it allows you to slap together those twelve commits where you were testing out stuff and making typos that you removed later, and just keep the two or three where you made actual progress and logical additions to your code.
You even get to edit all your commit messages in one handy list!
This is a decent tutorial: blog.ona.io/general/2016/02/02/squ...
Except for the part where they do a --force push. Don't do that unless you're working alone, or you hate your colleagues.
Personally I like to commit often and also push to remote often to backup the work. I use personal working branch in the remote so I can safely rebase and force push without interfering with others. Once the feature is ready, commits tidied up and merged to master (meant rebased with master and integrated), the personal branch can be deleted.
I recommend to use git flow. Feature branches reintegrate into develop using rebase. Its better than the personal branch way, because you can easy switch between features and work on multiple features or keep them back for later.
Push as many times as you want to feature branches, but rewrite history on rebase into develop.
This is exactly how I'm doing it. Personal branch == feature branch, and there can be many of them. It seems that I wrote "merged to master" when in fact I'm using rebase. Wrong choice of words, I will edit it :) Thanks.
+1 for this.
git rebase -i HEAD~...But make sure to be careful enough when you use interactive rebase on a branch where you and your teammates work on at the same time. Because your force push may affect others code base.
Our convention is that if the branch has your initials in the name (e.g. 'rl-new-nifty-feature'), then it's yours, and you're the only one allowed to rebase it. Other branches must not be rebased.
Indeed!
I've even have an alias for interactive rebase:
git rbi:)Where you leave commits is very subjective, and best left to the programmer to decide where the logical breaks should be. I follow these rules:
1) Start a new commit with a message describing your planned change immediately before doing any real work. Use an arbitrary file with a date or version number or whatever.
2) Commit frequently, --amend is your friend.
3) Don't be afraid to amend your commit message when you have to change your mind about what you need to do, but...
4) Stick to simple incremental changes that focus on the direction in which your program is evolving.
5) A commit (or its final amendment) must be a complete change, compile and run without obvious errors for all targets, and pass all tests.
I don't trust the local storage, I need to push from time to time. So I do WIP commits.
How do you handle this?
git merge --squash?Based on experience I don't use and recommend rebase, it's too powerful and ppl brake things.
I
rebasebefore merging my feature branch. This allows me to clean up any previous commits accordingly.Once I learned
git add -pandgit rebase -imy commits instantly improved.I like your approach. I started that way, then one day a hard drive got broken and I lost everything. Now I commit and push almost every 20-30 minutes on a non-production branch
You should not change your approach because of one edge case.
I know but first was the HDD, then a short circuit that started a fire (the pc burned), then the pc was stolen (second time in a series of 6 robberies) I trust more on my thumb-drive xD
Now I do as many copies that I can. I'll try the rebase comments. Just wanted to use the best process
sounds more like you should move to a nicer neighborhood lol
But really though, cloud storage is your friend. Nextcloud also exists if you would prefer to self-host - alternatively, if you're doing something with a lot of small files that get updated constantly, consider directly mounting a remote filesystem instead (lots of sync clients will trip over a high density of file changes per second)
now we have security Guards and surveillance cameras ;)
Ohh why I didn't think of that? Yes, that's a really nice solution. I'll have a backup and keep commits organized
A third context I seem to hit a lot is debugging something external. Eg if CI or the server is failing for some reason, I can't fix it locally, I might commit a series of changes trying to get it to do what I want. Or if I work on it on my computer, I might push so that I can pull on my Windows machine and run the tests there. It needs to pass tests on both environments, but it needs to be committed to travel between them.
Also, I sometimes leave WIP commits in b/c they include useful experiments / places I got to that I wasn't sure if they were useful or not. The final commit might be cleaned up and elegant, but seeing that intermediate state can be useful when you return to that code or API.
As someone who is just starting out it's tough to know "when" to commit. I've read countless resources about "how" to make a commit, but no one ever really explains when to do it. One of the comments asked about a new project, which is what I am about to embark on, your advice was to create small chunks of work to be done and commit those.
I just want to say thank you :), because that's what I am going to do with my project. It's already helping me focus on getting the right things done as well.
Excellent. I'm glad to hear this was helpful. Definitely checkout out my other articles on Git as well as the Getting Git video series.
Once again this discussion below has 2 types - enlightened and everyone else.
I agree with the rules, but we must emphasize master versus not master. I find most disagreement is between those who can't split the two. If you are working on master on a team you lack enlightenment, sorry brah, go back to GA and try to find an instructor who is not a burn out.
If not on master any of the reasons to commit are valid. If you commit each time your dog takes a healthy steamer on the kitchen floor, fine.
Just not on master.
When not on master (I work on local and scratch branches that never get published and squash/rebase) do as you wish. Fuck, I commit just so I can watch the diff when refactoring. I commit to make sure my cat doesn't not add some chars when I am outside the building drinking whiskey with some homeless guy. The ability to "revert to sober" is great.
What ever works for you...
Master should be squash/rebase/however you keep it clean.
I also recommend sobriety when intoxication is not appropriate.
Or is it the other way around?
I forget.
git commit --amend:)))))))But what about dealing with unnecessary large conflicts? Why give yourself another annoying thing to deal with? My team prefers to commit early and often to avoid conflicts upstream – this way we merge features instead epics.
What’s your advice on how to commit on a brand new project?
For example, when building out a server I find myself needing to do a lot of setup & I find it difficult to commit because I’m like “I’m not done yet!”
Break your work up into smaller chunks and commit those as they are ready. Maybe the project isn't done, but that piece of work is done.
There's nothing wrong with WIP commits, but based on what you described, it sounds like all your work is one big WIP commits. Which is obviously not helpful from a version control perspective.
Few weeks ago, I wrote a similar article about why and how creating small and useful commits: adopteungit.fr/en/methodology/2017...
Thanks for the great article. I’m passing this around to everyone at work; we need to get more consistent with when we perform commits.
That's awesome! Glad it was helpful.
Just do
git rebase -iand squash them into one!My eternal question on the matter is to include or not the test suite as part of the unit of work. Any thoughts on this?
Absolutely include it - the tests are part of the unit of work.
I also generally like to separate commits that do extensive refactorings or changes in code style etc.