Hacker News Reader

Comment by tonymet | Hacker News Reader

Git is a distributed system, meaning that you're supposed to have different histories.

Git gives you the tools to allow any member of the team to reconcile those histories cleanly for others.

Forcing everyone to be in sync all the time also means lots of merge conflicts.

Git allows for everyone to drift in their own way and provides tools for them to reconcile that drift in a way that others can integrate easily.

Until you embrace the distributed nature and start using tools to manage your history (rebase & reset) , you will suffer with git.

I cringe when editors refer to "rebase & reset" as "weird".

Rebase and reset are the primary power tools of git. Along with reflog, revert, interactive-add .

The worst repositories I've seen are people who `git merge` 20x a day to stay "in sync" and create labyrinthian change logs that are impossible to parse.

View on HN

Paying the cost of a distributed system for a centralized team of 10 is a horrible idea. Better for someone on the team to teach everyone else a simple set of rules (git checkout -b before starting a new featire, git pull --rebase origin to keep up to date, git push origin when you're done) and pretend Git is a centralized system as much as possible. You're anyway going to have a central server which is the source of truth. If your local copy goes bad, there's always rm -rf ./ && git clone. No reason to pretend your local history has some value.

Of course, if you are working on a highly distributed project, like the Linux kernel, many of the Git tools are absolutely invaluable. But there's no reason to bother with them if you're not.

I like your idea of feature branches, but people do need to know the data model and how to manage their history. They will inevitably be out of sync and clumsily tring to get merge all day to get their files in sync.

Keeping the history clean is more important than just syncing files.

Merging is a process that I like over rebasing exactly because it conserves the history.

With a repository server that supports merge requests and feedback from CI/CD tooling on commits/push you can motivate people to use merges rather cleanly.

If you add to that very simple rules like

- create branches for every feature

- commit often

- push often

- merge only via merge/pull requests

then even people new to Git can handle it just fine.

Merge conflicts happen when multiple people work on the same file and try to merge their different status. Imho, code bases where multiple people work on the same file at the same time have a more fundamental problem than Git.

Honestly, I still struggle to see the value in rebasing. Maybe because I haven't used it extensively. Superficially, to me at least, it does the same as a "git push -f".

I am curious to hear why it is supposed to be superior, especially with modern CI tools like Github and the likes.

Merge isn't superior to rebase; they're both tools with different purposes.

Have you ever squashed down a branch before merging back into main? Then you've used rebase.

The purpose of source control (not just git) is to keep a useful version history of your project. If you don't need to know where/when a commit originally branched off from, rebase can keep a cleaner history than merge.

Even rebasing a branch off the latest commit just to merge back in can be useful.

I never use squashing, because the history would not be easily accessible afterwards.

In popular Git ecosystems like Github you have the option to add a merge commit. To me, this also helps understanding the history of the repo. Would the rebasing be equally visible?

Rebasing is usually (but not exclusively) useful before pushing to the shared repo, at a point when there's no proper history being added to it yet, so you can put your changes into shape before actually publishing them. Learning how to effectively use rebase and its all goodies is one of the most useful things that git has to offer and almost transforms the way you work with version control, as with it you're able to utilize its power in more areas than if you only ever commit and push. For me, git is not just a collaboration tool - it's also an "undo" log on steroids; something that extends my text editor and lets me manage the changes regardless of whether they're meant to ever leave my PC or not.

Git is a powerful data structure manipulation tool. Use it as such and harvest that power. After all, what you're working on is just a graph of repository states - and you can attach any meaning you find useful to those states.

Rebase can split commits as well as combine them. Rebase can be used to improve the commit messages of previous commits, etc.

If the history is important, as you assert, then a tool for rewriting and improving the history is also important.

Arguably, it is not the real history anymore if you make it prettier.

Do you put manual work into rebases? It sounds like a lot of effort and time when collaborating.

It's not the full history, you're right. But nothing in git will ever be the full history.

git merge doesn't conserve the history it pollutes it. any more than a few merges or a few developers and you are left with an impossible to read merge log with 10+ parallel paths.

Git rebase preserves a linear history . Keep a reflog on the server (github has one built in) for cases where someone has screwed up the history. and secure shared branches to avoid clobbering it.

Yes, securing branches is very important, much like git-hooks if you are serious about the Git flow.

How do you specifically investigate the history with rebase and 10+ developers? Do you manually look into commits on the branch, or go by a single file history, or look at merge/pull requests?

Personally, I prefer looking at the context of a file change within a merge/pull request. The specific merged/pull request can be read from the merge commits. And in case a specific file history is of interest, I can backtrack from that file's associated commits.

if master has a clean history, then use git-blame on the file to see where a change was introduced, and git show to see the entire change. then you can walk back through the git log to understand the context of the change.

Merge doesn't pollute the repository. Just like rebase, it's a valid tool to use when what you want to do with your repo structure calls for it. It's the fact that most people use git blindly and end up doing things that don't make sense that pollutes their histories.

There are tons of merge commits in the Linux repository, but no useless ones. Note how in its nature Linux process also does implicit rebasing of applied patches when they land in subtrees.

There is more than one way to do it. If that workflow works for you, fine.

> I still struggle to see the value in rebasing. Maybe because I haven't used it extensively. Superficially, to me at least, it does the same as a "git push -f".

Rebasing is completely different from pushing. Rebasing changes your history. You can do whatever you want with your history: rebasing, creating personal branches and moving them around, etc... and no one will know. Only your pushes matter to the rest of the world, or alternatively when others pull from your repository. "git push -f" means you don't want to play along with whatever is in the repository you are pushing into, it is usually bad as it may desynchronize it from everyone else's fork. You absolutely don't need to do a "git push -f" with rebase, in fact you really shouldn't.

And none of your rules prevent rebasing. The commit/push often rule make the need for rebasing less likely, but if a dev did a rebase, no one will notice, it didn't leave his own machine. He mostly did that to make the commit he pushed less awkward.

This seems like a reasonable take - there's only one problem: you haven't told us how to draw the rest of the owl.

How does one learn how to (1) think in this way (which necessitates not only abstract description but multiple concrete examples) and (2) what workflows and commands are necessary to effectively implement this?

the team has 2 deliverables:

1. a ref (branch or tag) that builds (compiles & passes all tests including UAT)

2. every shared ref has a clean revision history that allows for graceful change management ( read changelog, fork, integrate, revert, A/B test)

Any ref shared by a team member (e.g. git push) must meet those two qualities. Team members must reconcile refs on their end (e.g. rebase) before they can submit a new ref meeting those expectations.

This way you are not prescribing a workflow (e.g. git-flow). The team needs to agree on that to their software delivery pipeline requirements.

In order to deliver these two expectations, they need to understand refs (pointers to a digraph) and how to manage them (rebase). tell them to RTFM the git manual on those topics.

Just like memory management, pointers, algos etc these skills are essential . They are not a "nice to have" to build software.

Reply on news.ycombinator.com