I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the “distributed” mindset didn’t happen overnight.
That other people would care as much for a clean history like I do. Specifically, opening branches and leaving them open forever without merging them back into main, many useless commits rather than squashing or amending, or making branches-of-branches-of-branches. Drives me nuts
Omg so this. Also merging main branches into feature branches instead of rebasing.
What is the advantage of rebasing?
What is the advantage of rebasing?
You get a cleaner history that removes noise from the run-of-the-mill commit auditing process. When you audit the history of a repo and you look into a feature branch, you do not care if in the middle of the work a developer merged with x or y branch. What you care about is what changes were made into mainline.
Good to know. Thanks.
Instead of a commit history, you get a commit fairy tale, which is prettier than the truth, but probably less useful. You get something akin to merging the base branch into the feature branch but things look as if they were done in an order they weren’t instead of getting an ‘ugly’ merge commit.
In many providers it’s possible to set up an automatic squash policy when merging to main. At our company the git history is just linear with well defined commits.
I don’t think this is necessarily better. Some branches/projects are big enough that there are meaningful commits that should be made inside the project.
Yeah I agree but in my experience developers seem to struggle with “keep important things in history; squash unimportant things”. An open “merges allowed” policy leads to people unthinkingly merging branches with 50 “typo”, “fix” commits for a 100 line change.
Dunno what the answer is there.
The answer is Gerrit and learning interactive rebase.
How does that help?
The key thing gerrit provides is relation chains. You can push to the server your local branch and it will make a “patch” (like a pull request) for each of the commits in your branch. The patches are automatically put into a relation chain which lets reviewers go through them in sequence. Also your CI can test them together.
The idea is you need to locally make your commits ready for master. This is where interactive rebase comes in. You’ll have a normal local working branch and when you’re ready for review you use interactive rebase to squash some commits together, redo the commit message on some, change the order, etc. Basically you clean up your working branch into a series of commits ready for main.
Being able to easily push a relation chain of reviews up makes it way easier to make commits that land on main that just do one thing.
The second part of the solution gerrit provides is patchsets. When you need to edit a patch to deal with review comments, you actually rewrite your local history using git commit —amend or interactive rebase and push to gerrit again. In gerrit this will make a new patchset of your patch that you can diff between, see comments on, etc. It works very well for dealing with review feedback and for reviewers to quickly rereview.
It achieves this magic through a change-id that is added via git hook to the commit message. Even if you rewrite your history and your commit id changes it will still consider the rewritten commit to be the same patch as long as the change-id stays the same.
It’s pretty hard to just explain it like this. Using the workflow for a bit makes it much easier to see the value it has.
Yeah I get what you’re saying. Gitlab can pretty much do that too, you just need a branch & MR for each commit, and then you tell it to merge each branch into the previous one. It automatically rebases them when their dependency merges.
Definitely more tedious to set up than just pushing one branch though. Maybe I should make a tool for that… Does Gerrit test each patch in CI sequentially or just all of them together?
But in any case that wasn’t really the problem I was talking about. What I’m saying is that whether or not you should squash a branch depends on what that branch is. Neither “always squash” not “never squash” are right. It depends. And developers seem to have a real problem with knowing when a change is important enough to warrant a commit.
Though I suppose if people have to actually review each commit they would get a lot more push-back to “fix fix fix” type commits so maybe you are right.
Does Gerrit require each individual commit to be approved or can you just approve the whole branch/changeset?
I guess it’s dependent on project, but IMO if a commit is important enough to be in the main branch, then that should have its own merge request. I like it when all commits in the main branch have gone through all the build pipelines and verification processes.
But if having separate MRs is undesirable, then you could always overrule the squash policy. I know it’s possible on Gitlab at least.
Commits should be reasonably small, logical, and atomic. MRs represent a larger body of work than a commit in many cases. My average number of (intentionally crafted) commits is like 3-5 in an MR. I do not want these commits squashed. If they should be squashed, I would have done so before making the MR.
People should actually just give a damn and craft a quality history for their MRs. It makes reviewing way easier, makes stuff like
git blameandgit bisectway more useful, makes it possible to actually make targeted revert commits if necessary, makes cherry picking a lot more useful, and so much more.Merge squashing everything is just a shitty band-aid on poor commit hygiene. You just get a history of huge, inscrutable commits and actively make it harder for people to understand the history of the repo.
Well the MRs in the teams I’ve been working in have been small and mostly atomic. They’re focused on solving only one thing.
The team I’m currently working now in was bad at this before and often bundled way too many things in a single MR. It lead to overly long review processes and was error prone. It was too tough for the reviewer to get an understanding of what was going on.
Since we made the habit to make smaller MRs we have had much less of those issues.
If the MR is anything bigger than a completely trivial change in a file or 2, it most likely should be broken into multiple commits.
A feature is not atomic. It has many parts that comprise the whole.
In that case the feature is multiple MRs.
I’m glad I was able to establish a very mindful and structured approach to Git history in my team and project.
I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.
There are no strict rules for how you should use git, it’s just a tool, with some guidelines what would probably work best in certain scenarios. And it’s fine diverge from those guidelines, add or remove some extra steps depending on what kinda project or team-structure you’re working in.
If you’re new to Git, you probably shouldn’t just lookup Gitflow, structure your branches like that, and stick strictly to it. It’s gonna be a bit of trial-and-error and altering the flow to create a setup that works best
I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.
I don’t think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it’s a trait of Git is like complaining that Java is hard because you need to use camelCase.
Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.
Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used “gitflow” as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.
But there’s nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you’re using it and it seems more practical to adapt the flow for your own use-case, don’t worry it’d be considered wrong to not stick strictly to it
Git’s internals are very easy to understand and once you know more about them, you’ll have a much better idea of how it works (especially when it comes to tags and branches). They’re so simple, you could even easily write your own scripts to parse git’s internal data directory if you wanted to.
I would highly recommend reading about them: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#
They’re not that simple because of packfiles. But yeah loose files are very simple. Also the documentation for packfiles is pretty bad. You end up reading other people’s random notes and the Git source code. (I actually have written a Git client from scratch.)
All I will need is push, pull, and commit.
Sure if you never branch, which is a severely limited way of using git.
Network engineer doing netdevops. branches don’t work like software, always commit to main.
Sure if you never branch, which is a severely limited way of using git.
It’s quite possible to use Git without creating branches. Services like GitHub can automatically create feature branches for you as part of their ticket-management workflow. With those tools, you start to work on a ticket, you fetch the repo, and a fancy branch is already there for you to use.
You also don’t merge branches because that happens when you click on a button on a PR.
Coming from SVN and Mercurial where commits are increasing integers, I thought the SHA-1 stuff would be a PITA. It’s not and no one cares about numbers anymore.
It’s not and no one cares about numbers anymore.
The only people who ever cared about svn’s numbering scheme were those who abused it as a proxy to release/build versions, which was blaming the tools for the problems they created for themselves.
That it’s just like subversion but distributed. Both of those assumptions are wrong. It uses a lot of the same terminology as subversion, but most of the terms are conceptually different in sometimes major ways. It’s not really distributed unless you go out of your way to make it so. Most implementations use a single remote to sync back to on a regular basis. It is, however, really good about keeping changes in sequence locally until it can sync, something you can’t really do in subversion.
I expected any operation involving
origin/foobarto be an online operation and work against the latest server-side version of the branch.I didn’t expect it to keep a local copy of the remote branch instead.
I thought it would be hard to use and confusing all the time.
I don’t actually remember when I first learned Git. Maybe it was in a university lecture. I think my biggest struggles was learning how to resolve merge conflicts properly and efficient use of branching, but I never found any of the commands difficult to understand.
I tried to follow tutorials that use the command line. In hindsight that is terrible way to teach Git, which is fundamentally quite a visual thing.
It’s like trying to teach people about filesystems only using
cd,lsandpwdinstead of just showing them a file tree.Actually it’s even worse because Git’s CLI is so notoriously awful.
Eventually I tried Sourcetree which made it all make sense. Though Sourcetree isn’t a very good GUI, mainly due to being hella slow. I eventually switched to GitX which is probably the best GUI I’ve used so far and makes everything extremely clear and easy. Unfortunately Mac only.
I now mostly use the Git Graph VSCode extension which is excellent and integrates pretty well with VSCode. Unfortunately it has been abandoned by its author and they frustratingly included a license clause saying only they could release versions of it, so it’s basically abandonware. But it still works so I’ll figure out a replacement when I have to.
Oh dang, I use that extension too and I didn’t know it was abandoned. Let me know if you find a good replacement
If you use the git command line (and I do) you should spam
git log --graph(usualy with--oneline).And for your filesystem example I sure do hope you use
tree!you should spam git log --graph
Yeah… but that’s just a poor man’s GUI. Why use that when you can use a proper GUI? The only reason I can think of is if you happen to be in a situation where using a GUI is a bit of a pain (e.g. SSH).
It’s a question of workflow. Git doesn’t guide you (it’s really workflow agnostic) and I find it easier to taillor CLI to fit my exact need, or use whatever was recently added (like worktrees a few years ago). I have yet to find a GUI/TUI that I’m not frustrated with at one point but everyone has its own preferences.
Wft isn’t there just a nice clean git UI that tells you in human terms what you are doing.
Command line interfaces suck ass.
I think the lack of UI is the main reason for all the jokes about git being horrible to learn. Fork is a pretty good client, and there are also some pretty good VSCode plugins to show you how all the commits and branches fit together.
think the lack of UI
Even git ships with git-ui. It’s not great, but just goes to show how well informed and valid your criticism is.
Tbf I’ve been using Git for at least 10 years and I only just discovered this. I think nobody talks about it because it doesn’t show history which is 90% of the reason to use a Git GUI.
I think nobody talks about it because it doesn’t show history
What do you mean it doesn’t show history? It’s perhaps the only thing it handles better than most third-party git GUIs.
git: 'gui' is not a git command. See 'git --help'.If you’re going to try to smack talk like Linus Torvalds then maybe check your facts first
Git Fork is amazing
Sublime Merge is the best. Not easy but I’ve tried them all.
I’ve tried them all. Didn’t get on with Sublime Merge.
My recommendations:
- GitX (sadly Mac only, and a confusing array of forks).
- Git Extensions (which I avoided for ages because the terrible name makes it sound like it’s just explorer shell extensions but it’s actually a full GUI).
- Git Graph VSCode extension
Most of the others are kind of crap IMO.
I mean gitlab is pretty sweet
