I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At some point one has to say that enough is enough. I really want to put the 'enough is enough' point before worrying about a good looking commit history. Some years ago we all went from svn to git and I am not really sure the improvement was worth it. Sure, git is objectively the better version control system. One can do a lot more things in git. But then the disadvantage is that one actually gets to think about all of these 'a lot more things'. One thinks about questions like should one merge or rebase and so on. I seems like an activity that falls under what is commonly called 'bike shedding'. But like I was asking before: is this really worth it?
> Does this mean one per product, program, library, class? Only you can say. However, dividing stuff up later is annoying and leads to rewriting public history or duplicative or missing history. Dividing it up correctly beforehand is much better.<p>Got it, simply devise the correct level of modularization for an increasingly complex project at the beginning of time, to avoid annoyances. Easy peasy. /s<p>Git actually has tools to separate paths into their own repositories with intact histories, so I recommend the opposite.
One of the more challenging parts of git for people to understand is that many of its tools and concepts serve many purposes. Commits are a good example of this. To git, a commit is a very simple and precisely defined thing. But what they represent is basically up to you.<p>One thing they could represent is your current work as of this minute. This is really useful to you while you're working in case you break something and need to revert. But it has very little use to anyone else. Nobody needs or wants to know the history of a project down to the minute. How long it took you to develop a feature and how many times you messed up is completely irrelevant to the project a week from now. So these commits should remain private.<p>Another thing they could represent is <i>versions</i>. What's a version? It's a fully valid and working copy of the project that anyone could use. These are the commits that should end up on the master branch. Sometimes it's possible to write these first time (for bug fixes or trivial stuff), but most of the time they need to be curated and constructed from the work done using the previous type of commit.<p>If history is worth keeping, it's worth maintaining. If you don't think it's worth, delete your history.
> Once you git push (or in theory someone pulls from your repo, but people who pull from a working repo often deserve what they get) your changes to the authoritative upstream repository or otherwise make the commits or tags publicly visible, you should ideally consider those commits etched in diamond for all eternity.<p>I've broken this rule multiple times per day for the past 10 years.<p>On your own feature branches, rebase your fucking shit and force push. I see so many people creating ungodly messes because they never want to erase the history of PRs that they've submitted and its just a nightmare of merge commits pulled back into their branch from master.<p>I've watched a decade of git n00bs practice this "never under any circumstances rewrite history" advice and it fucks them up over and over and over again.<p>Nobody actually cares about the exactly commit process you went through to fix the bug. Squash everything and rebase. Leave a SUMMARY of why you did what you did in the PR and/or commit message. Humans have this amazing ability to write stories about what they did after the fact.<p>I'll frequently leave my-future-self notes on closed and merged PRs as I think about them post-merge, where I document what approaches were rejected, and what approaches might be worthwhile if the change isn't sufficient. Stuff like "I could not do WWWW because of <great sadness>, so instead we must do XXXX, if this is not sufficient because <unlikely edge condition turns out to be not so unlikely after all> then we must consider that YYYYY will be less preferable due to <stuff i was thinking about hard> and we should consider doing ZZZZZ first". If all you do is capture "what did I change" and don't capture your thinking and what you view to be all the different alternatives while your mind is still fresh with the problem then you're just throwing away useful information, which is what the "preserve your git history" approach does.<p>In the future, when I read my PRs I just don't care about how I got there. I care about what I was thinking about. So I write down, long-form, what I was thinking about. A git history is about going from A to B, it might document why you bailed on going to C, but it probably doesn't capture the stuff you rejected the whole time like D E and F and why. And really I'd PREFER to read a good note on why C sucked as a solution. I don't need to see the code that went down the route of C until it turned into a mess and then had to be backed out.
I don't know if anyone felt the same way, but I felt I "knew" how to use git before I read tutorials about how to use git.<p>Sometimes I felt tutorials were making it seem harder, more mystical, than it really was, or relied on "marble diagrams" with arrows pointing backwards, which I felt was unintuitive.<p>I had used SVN quite a bit, and found you can use git in pretty much the same way, but branching was easier.<p>And if you're using branches more, then "rebasing" your branch made sense, and the fact that you could "rewrite history", which I remember to some people seemed controversial, but the idea was it was fine, if you kept your branch private, or added caveats.
This is still pretty superstitious, even if it's better than a lot of the stuff Github has unfortunately trained people to do. Maybe I'm naive, but I don't think git usage has to be based on superstition and fear. I have never not been able to clear up people's random-internet-post-induced / github-induced confusion in about half an hour of personal communication.<p>Your goal in making a history is to make a meaningful, useful history that expresses information. I don't think this is hard. I think a lot of people don't want to do it, which isn't my problem (unless I have to work with you), but I also think a lot of people do want to do it and are stymied by posts like this, or by services like Github.
I agree with most of TFA. However, I urge everyone to start with a monorepo. Splitting a single project (developed by one team) into multiple repos will seriously slow things down later. I've seen it happen.
I use Git the best I can (read: I am by no means Mr Git). I try to read these type of articles and I too often feel inadequate (i.e., there's not enough explanation on what, why, and why that matters). Real life examples would help a lot. Else I have to try to imagine the appropriate situation for each recommendation; and frankly I can't always do that. There are more possible scenarios than I have experiences.<p>There's got to be a better way. Does learning and/or using have to feel so complicated?
I am beyond sick of hearing about 'best practices' for everything. It is such an obnoxious statement! So often it is used as replacement for 'in my opinion' because it brooks no argument -- these are the BEST practices!
Create a branch, do frequent commits with messages like "wip", "bug city", "wtf", prior to merge squash and create message referencing the objective of the commits and what they accomplished.
Some great advice. Interesting the explicit references to IRC and email, which is (unfortunately? perhaps?) out of date in these days of github issues and Slack.<p>The original article is 2012 with PRs back to 2016.<p>My current gig is part of a microfrontend/microservices scheme where each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with more planned. All of these merge into a single web application. It all works shockingly better than might be expected, but it takes a culture of constant vigilance and care along with automated integration including lerna, yalc, renovate, artifactory, et. al.<p>For our team, the branch management scheme is 1 branch per JIRA ticket, then PR with automated checks including tests, lints, code review. The dev decides whether to merge, squash or rebase to master with some input from the lead. That master is just for the microservice, which may or may not need to be merged into another parent service.
> If you think about it, movies are made this way. Scenes are shot out of temporal order, multiple times, and different bits are picked from this camera and that camera. Without examining the analogy too closely, this is similar to how different git commits might be viewed. Once you have everything in the “can” (repository) you go back and in post-production, you edit and splice everything together to form individual cuts and scenes, sometimes perhaps even doing some digital editing of the resulting product.<p>Except the end product is a movie, and my end product is software, not a commit history. If you want to draw an analogy to movies, then rebasing your history would be like movies throwing out raw camera footage because they have the end product. They keep <i>all</i> of the <i>raw</i> footage. They do <i>not</i> throw it out by "rebasing".
I haven't read it all but this could be great material as a git-mindset booklet for a team. Great to see someone taking the time to put down common sense notes about working with git, rather than yet another dry "this is how git works" or "this is how you should use git (because i told you)".
In my workflow, I typically commit often and use the commits as personal checkpoints. Once a pull request is ready I simply squash the commits and merge. That way, the history in the main branch is clean and I have my checkpoints. I assume that is a typical workflow for many teams.
I'm a beginner at Git. I coded in a hospital system where I was told not to use Git. Upgraded jobs, now I'm using it for the first time.<p>Wow! What a difference. I have to say the ability to see what I've done over time, to not have endless files labeled with the date and my initials, not having to manually write down what I'm up to...this is heavenly.<p>My main gripe would be the opaqueness of git. It really wasn't intuitive, I had to use it a few days before the vocabulary made sense, push, pull, commit, add, origin, they didn't logically click for me that fast.
I beleive that in feature-branch workflow it is totally okay to rewrite history of the branch before merging it into master. The only case when it is obviously wrong is when several engineers are working on the same feature branch, which is against all methodologies known to me (except the duration of code review, when reviewers may pull the branch to run tests or use IDE on it).<p>Having atomic semantic idiomatic changes in history beats short term branch immutability with one hand tied.
This is not a best practice.<p>Detecting problems is finding a needle in a haystack.<p>If you want to be efficient at finding the needle in the haystack, you make the haystack smaller.<p>That is what code review is about. You do not scan the entire source code for defects, only the new code being added.<p>You can commit often to your own branch, and submit for code review once it's stable.
Discussed a bit at the time:<p><i>Commit Often, Perfect Later, Publish Once: Git Best Practices</i> - <a href="https://news.ycombinator.com/item?id=6138928" rel="nofollow">https://news.ycombinator.com/item?id=6138928</a> - Aug 2013 (4 comments)
My simple strategy was to avoid fast-forward on merge and to use "git pull --rebase" when my changes are not critical. History rewriting? Hum I do not know....I do not like changing history
> Personally, I commit early and often and then let the sausage making be seen by all except in the most formal of circumstances. [...] For a less formal usage [...] I let people see what really happened.<p>> Whenever I pull, under most circumstances I git pull --rebase.<p>These 2 statements are contradictory. By doing a "pull --rebase" you hide the (maybe important) fact that your commits were written in another context.