3 ms·

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 tho

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.

tsimionescu 3y ago
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.
- tonymet 3y ago
  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.
fouric 3y ago
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?
- deleted 3y ago
  [deleted]
- tonymet 3y ago
  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.
riperoni 3y ago
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.
- adamsilkey 3y ago
  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.
  - riperoni 3y ago
    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?
    - seba_dos1 3y ago
      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.

tsimionescu 3y ago

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.

tonymet 3y ago
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.

fouric 3y ago

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?

deleted 3y ago
[deleted]
tonymet 3y ago
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.

riperoni 3y ago

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.

adamsilkey 3y ago
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.
- riperoni 3y ago
  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?
  - seba_dos1 3y ago
    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.