33 ms·

A beginner's guide to Git version control

277 points by freedude 3y ago

gpspake 3y ago
I think this is a good guide. Git tends to be an emotional topic for a lot of people - myself included - and the hill I dramatically die on time and time again is that I think, tragically, this is about where developers stop learning git. I think operations like rebase, cherrypick, and squash are just as important as some of the ones you first encounter. Especially when you're working with other people. I use them every day and I see some of the spaghetti experienced developers pile on the graph because they only know merge. I guess my point is "don't sleep on rebasing" :)
- jkubicek 3y ago
  Git is one of those tools that exposes so much of the underlying infrastructure that people just can't help diving in and making their own lives so much more difficult. After using git for well over a decade, I'm completely convinced that if you find yourself frequently rebasing/cherry-picking/reflogging you're using git wrong.
  - hughesjj 3y ago
    .... Why not rebase before merging into main?
    - entangledqubit 3y ago
      I'm a big fan of that practice but I get the impression that rebasing scares a lot of devs that either didn't take the time to learn git or are still recovering from that one time that their change got too far away from mainline. That latter reason is why I prefer the practice actually...
      - nerdponx 3y ago
        Or they were taught Git the wrong way, by memorizing a bunch of commands, as in TFA.
      - hughesjj 3y ago
        When in doubt, git diff main>~/patch.out (... && Git checkout main && git pull --rebase && git checkout -B clean_branch && git apply ~/patch.out) (I like the light rhyming of the first part)
    - jkubicek 3y ago
      Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts, with the added bonus that rebasing can sometimes force you to resolve conflicts for each commit in your branch. Here's how I think everyone should use git: 1. Create a new branch for your changes 2. Make commits and merge from main with wild abandon 3. One final merge from main 4. Squash everything into a single commit, push a PR If you keep your branch focused on only a single change, the end result is a tight, focused, single commit PR that merges cleanly into main and didn't involve any complex or error-prone shenanigans.
      - skeeter2020 3y ago
        This is a very common workflow for larger OS projects, and I think it translates really well to corporate environments too. It reinforces some work/feature discipline and gives you a nice clean history.
      - crispyambulance 3y ago
        This is how I do it. Almost never touch rebase. Also, I hate git :-)
        jkubicek 3y ago
        I love git, but I also never touch rebase. It's there when I need it, but I also work in such a way to never need it.
      - hughesjj 3y ago
        So, I get the "squash your feature branch into a single commit before merging upstream", but what does doing "git merge main" instead of "git rebase -i main" give you? (Assume I have my global git config to remember conflict resolutions via rerere)
      - seba_dos1 3y ago
        > Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts The opposite is true: resolving a conflict during a rebase is much easier, as you get to resolve the conflict in the context of a single commit and its parent. In some cases it may end up being more work than resolving a whole merge, but it's much easier to reason about.
  - nerdponx 3y ago
    I've been using Git for the same length of time, but I have not reached this conclusion. That's the problem with teaching someone how to use a very powerful flexible tool that accommodates a variety of workflows and styles: different people use it differently.
  - RandallBrown 3y ago
    I use rebase multiple times per day. Mostly for putting my changes on top of the latest development branch, but also for squashing commits. I'm curious why you don't like it?
    - jkubicek 3y ago
      My branches are always focused on a single atomic change†, so if I want the tip of my branch to be up-to-date with main (or the dev branch or whatever), merging from that branch accomplishes the same thing with a lower likelihood of conflicts. I always squash‡ before pushing a PR, so the end result is identical to a carefully rebased PR. † occasionally branches will need to be split into separate commits, but that's not my default working style ‡ I know `squash` is a rebase under the hood, but it won't ever result in conflicts, so I'm happy to use it with every PR
      - nordsieck 3y ago
        I think you'd get a lot less pushback if you mentioned that you squash every branch before merging in your original comment. That actually seems like a pretty good policy if you can keep your branches relatively small.
    - recursive 3y ago
      How/why do you use rebase for squashing?
      - seba_dos1 3y ago
        Rebase is pretty much just an automation for cherry-picking and squashing, and interactive rebase is the primary and most convenient way to put the branch you have worked on into shape before presenting it to someone else. When I hear about people not using rebase in their daily workflow, I imagine myself 10 years ago when I barely knew git and couldn't really use it as a helpful tool like I do today. It's almost like looking back to before I started using VCS in the first place - somehow I did manage to not use one for years (even collaborated via FTP!), but now it seems impossible. Usually most of the useful magic with git happens before anything gets pushed out, and `git rebase` has a huge part in it.
  - Espressosaurus 3y ago
    I agree that if you're having to use the reflog frequently, you're using git wrong (not least of which because the reflog is not designed for readability and understanding the context where it came from). But for the rest? If you're working in a repo with more than 5 people, rebase, cherry-pick, and squash are necessary to keep your sanity. Merge nodes are awful once you get beyond more than maybe 3 developers.
    - jkubicek 3y ago
      Someone else pointed out that it's probably confusing that I didn't mention that I do religiously squash my branches before committing, so we still have multiple developers with a clean main branch and no merge commits.
    - recursive 3y ago
      I usually use reflog to answer the question "What was the name of the branch I was just working on again?" What's supposed to be wrong with that?
      - pcthrowaway 3y ago
        That's perfectly reasonable IMO. If you just need to checkout the last branch you can also `git checkout -`
      - jkubicek 3y ago
        git config --global alias.recent for-each-ref --count=20 --sort=-committerdate --format='%(committerdate:short): %(refname:short)' refs/heads/ use it like > git recent 2023-08-07: jimkubicek/add-journal-table-creator 2023-08-07: main 2023-07-28: backup/git-squash-to-main 2023-07-28: backup/cleanup
  - no_wizard 3y ago
    rebase and cherry picking are both cornerstones of trunk based development workflows, and those have proven to be extremely successful in my experience, vs other methods (like Git Flow, the GitHub overly simplistic branch per feature and merge approach, which feels like trunk based but isn't etc.) rebase makes roll backs extremely easy if you need to roll back specific commits because of bugs and makes releases easier via cherry picking (so you don't slow down trunk merges just to do a release) and allow for fine grained continuous deployment that is harder to achieve than without it. It is my experience however, that either everyone needs to rebase or you end up with issues eventually when only some developers are and other ones aren't. I don't care as much for squashing myself as a general case, as you lose fine grained per commit rollback strategies though
    - nordsieck 3y ago
      > It is my experience however, that either everyone needs to rebase or you end up with issues eventually when only some developers are and other ones aren't. The only time I merge is when I'm working on a shared remote branch. I haven't found a workflow (although I'm all ears if you have any suggestions).
      - sixstringtheory 3y ago
        Here's my current workflow: 1. write some code on a local branch 2. upstream has new revisions? rebase my branch on top 3. if not finished with my task yet, go to 1 4. if ready for review, open PR 5. if accepted, squash and merge 6. if changes are requested, write more code 7. upstream got more commits causing a conflict? don't rebase! it will screw up the PR history on GitHub and can cause issues for reviewers who might've checked out your branch locally and maybe done some experiments. merge upstream into your local branch. then you can push fast-forwardable commits. 8. push new commits to PR and go to 5 I used to think of rebasing as just rewriting commit history. But now I also think of it as altering the history of collaboration that is captured in a PR. So I switched from rebasing onto new upstream base branch commits and force pushing to PRs that already had reviews, to merging in new upstream base branch changes. I only do this after someone else has done anything on my PR; if I open it but nobody has reviewed yet, I'll do the rebase/forcepush to keep it current until someone does. I prefer squashing to merge because I prefer the default branch to have one commit per unit of collaborative work. The way different people split up commits on a branch is arbitrary and varies widely; you'll never get more than 2 engineers to agree on a convention here. Keep all the messy stuff in the PR, and you can always revert one of those individual commits if you want finer-grained rollback. If you want a PR to have generated more than one commit, then it should be more than one PR.
  - lcnPylGDnU4H9OF 3y ago
    > I'm completely convinced that if you find yourself frequently [cherry-picking] you're using git wrong. A previous employer had a multi-tenant application that was deployed as a client-specific application which loaded the "core" as a dependency. They didn't really know how to do versioning and most version changes were just arbitrary "I feel like we should call it 1.8 now". At one point I ended up maintaining a client-specific branch of the core dependency on version 1.10 (branch was 1.10-$CLIENT) while the "main" branch was 2.3 or something. For context, it went 1.10 to 2.0 because general cognitive dissonance. This meant any change that needed to be made in the application core for this particular client also needed to be cherry-picked in some direction, usually by making the change on the client branch and cherry-picking it back as necessary. In some cases another client -- naturally, they would be on a separate branch like 2.3-$CLIENT -- also wanted that change so it needed to be cherry-picked again to that branch. The result was a minimum of two PRs, one a cherry-pick of the others' commits (one commit unless I felt like spending my time in self-loathing), that I would make for every change. Not knocking cherry-pick at all; it's wonderfully useful when used correctly. That's just the result of non-technical decision-makers making decisions about technical tools. On the plus side, I learned a ton about git in that job.
  - jsunderland323 3y ago
    If you’re doing collaborative trunk based development then you’re only cherry-picking. So far Dave Farley is the only person I’ve ever heard advocate for this but it does have its place in the universe. Cherry picking is not destructive to history fwiw. There’s absolutely nothing wrong with rebasing/squashing/amending/resetting heads on personal feature branches. In fact, it’s a pretty good practice if you make messy history and can make PRs less of an eyesore. I think the confusion comes up about when destructive history operations are appropriate because the git cli client does not have a concept of protected (shared) branches vs feature branches. As long as you keep history destructive operations away from shared branches, you’re good.
    - seba_dos1 3y ago
      In some cases, you're still good even when rewriting shared branches. At work we're maintaining a downstream Linux tree with a few hundred patches on top of mainline. The tree gets frequently rebased on top of new upstream releases, and some changes are being progressively upstreamed. It's much easier to reason about the remaining downstream changes and deal with conflicts when rebasing than when merging upstream releases back into the downstream tree. Of course you can't expect to be able to carelessly `git pull` in such workflow, but if you're working with people who actually know how to use git it's not really a big deal. Naturally, this particular project uses a special workflow that fits its needs. It doesn't usually make sense to rewrite shared branches in projects where you're the upstream.
      - deleted 3y ago
        [deleted]
    - jkubicek 3y ago
      I don't understand this: > If you’re doing collaborative trunk based development then you’re only cherry-picking. All my work is collaborative trunk based development, and I never cherry-pick. > There’s absolutely nothing wrong with rebasing/squashing/amending/resetting heads on personal feature branches. I agree that there's nothing _wrong_ with it, just that it's unnecessary. If your branches are focused on a single feature and you're always squashing your PRs to main, the cleanliness of the branch while you're working on it is unimportant.
  - User23 3y ago
    I can’t imagine using VC for exploratory programming without rebase or something equivalent. I don’t want to bother writing a meaningful commit message for a change I’m probably going to throw away. I also don’t want to push a history like “WIP, WIP, works now, broke again, WIP” and that’s what it looks like at a first pass when I’m moving quickly. Instead I squash away the garbage and push out a reasonable looking chain of commits with nice descriptions.
  - jayd16 3y ago
    How do you pull a critical fix across branches w/o the occasional cherry pick? What do you do instead?
  - p1necone 3y ago
    As long as you never ever cherry-pick from one branch to another when the source branch is intended to eventually be actually merged (directly or indirectly) into the destination branch I think it has its use cases. If you break this rule you could be in for dealing with some atrocious merge conflicts though, so I try not to do it unless the branch I'm cherry picking from is a definite actual dead end (e.g. the change was an urgent hotfix against an old release branch and your workflow doesn't involve merging those back into main/master).
    - doix 3y ago
      Is that really an issue? When you rebase, git automatically figures out that you've cherry-picked something and will skip it. I will occasionally chery-pick something from master, do my work etc. Before making my PR, I'll rebase against master and potentially squash/reorganize my commits. When the PR eventually gets merged to master there aren't any problems. I don't think I ever merge without rebasing though, so maybe rebase has been saving me from any potential problems.
      - p1necone 3y ago
        Yeah I very rarely rebase, just autosquash PR commits into one on merge to master (and also delete the source branch to avoid similar headaches) + making sure PRs are fairly small and focused. Regular merges where commits have been cherry picked from one side to another, and then later also unmerged changes have touched those same files tend to result in a lot of spurious merge conflicts.
  - u801e 3y ago
    > I'm completely convinced that if you find yourself frequently rebasing/cherry-picking/reflogging you're using git wrong. A lot of people want to use git as a checkpoint/backup system, and commits and associated changes reflect that. The rebasing/cherry-picking/reflogging is one way to update the set of commits on the branch in order to make a set of meaningful commits for the feature branch they're working on.
- zwieback 3y ago
  If you use those commands in your local repo to keep the central shared repo clean then yeah, rebase and friends are great.
StevenXC 3y ago
I've been working a bit the past week on a guide for a workshop I'll be running in a few months to get research mathematicians productive using just GitHub's UI. [0] So the purpose is not identical by any means. But I'm curious whether it's appropriate that this RedHat guide seems to go straight into "what commands do I run" rather than answering/illustrating "how does Git model the history of a software project's files". [0]: http://jmm2024.clontz.org/ http://jmm2024.clontz.org/
- nerdponx 3y ago
  The #1 mistake in trying to teach people Git is jumping right to commands without developing a mental model first. It leads to nothing but confusion down the line, and reliance on copy/paste of snippets and scripts to get anything done. Effective usage of Git depends heavily on having a basic understanding of how it works, moreso than a lot of other tools.
  - IshKebab 3y ago
    Definitely a mistake, though you can explain Git's data model in about 2 minutes. I would say a bigger mistake is starting with the command line. A good GUI is absolutely instrumental to understanding Git, and it lets you avoid Git's terrible CLI for as long as possible.
    - nerdponx 3y ago
      Interesting about starting with the GUI. I can see it being useful in a controlled learning environment where you start with the GUI and gradually transition to the CLI. But if you stay on the GUI too long the student might suffer because they eventually will need to use the CLI, or at least understand its vocabulary, in order to read the documentation and get help from other people.
    - memefrog 3y ago
      I totally disagree. GUIs inevitably confuse people about git. I have never met anyone that used a GUI for git that actually understood it.
chiefalchemist 3y ago
This guide would benefit from some visuals. That is, what is happening, and why. Else, for beginners, just listing commands is too abstract. It would also help to elaborate a bit on why, or at least walk though a merge conflict, 'cause ultimately, that's what beginners need to be aware of. That is, Dev A made changes a file and Dev B also made changes to that file. Boom! But this is why we use Git.
- nerdponx 3y ago
  The Git book, Pro Git, does a decent job of this. Also https://learngitbranching.js.org/ https://learngitbranching.js.org/
  - chiefalchemist 3y ago
    I believe that on GitHub there are also visual examples. For me, ultimately, Git is best understood when there are visuals. The command line is cool, but if there's a tool that begs for a UI it's Git. Yeah, I know there are Git UI tools, so many the article should have suggested some of those as well?
    - nerdponx 3y ago
      I have yet to find a Git GUI that really feels right. Recommendations?
      - chiefalchemist 3y ago
        I've been using GitKraken which is paid (@ a fair $60 p/y). But I also see FOSS options mentioned on HN from time to time and intend to explore one of those. Perhaps I'll do an Ask HN later today?
jehb 3y ago
Fun fact, when I worked at Red Hat for many years on the Opensource.com project, we created a collection of dozens of great articles on the ins and outs of git, written by open source community members. You can still find most of those articles here: https://opensource.com/tags/git https://opensource.com/tags/git Unfortunately, the team who ran site got caught up in Red Hat's layoffs earlier this year and the site has been sitting in limbo ever since, so I don't know what will happen to it long term.
- pabs3 3y ago
  ArchiveTeam saved the entire site to archive.org using ArchiveBot, except for the downloads, since those were loginwalled. If you are able to contact whoever still has access, it would be great to be able to save the downloads too. It looks like the team or someone from it are planning on continuing the site though? https://wiki.archiveteam.org/?title=ArchiveBot https://wiki.archiveteam.org/?title=ArchiveBot https://archive.fart.website/archivebot/viewer/domain/opensource.com https://archive.fart.website/archivebot/viewer/domain/openso... https://opensource.com/article/23/6/new-developments-opensourcecom https://opensource.com/article/23/6/new-developments-opensou...
micw 3y ago
A short explaination what remotes are and how to configure it would be helpfull. Otherwise, the "git push" command would fail and the tutorial gives no hint, why.
criddell 3y ago
This image helped me a lot: https://nitter.net/pic/orig/media%2FFjJ62xKXkAYfFjt.jpg https://nitter.net/pic/orig/media%2FFjJ62xKXkAYfFjt.jpg
- nelsonfigueroa 3y ago
  Wow this is great. Wish I came across something like this back when I was learning git.
- boneitis 3y ago
  As someone who's having a very difficult time coming to grips with git, would really appreciate another source for this. It does not load for me, in the eight ways I have tried to load it (two devices each on a different IP, on two browsers, with that %2F left encoded and attempted with it unencoded.)
  - 6581 3y ago
    https://twitter.com/bibryam/status/1601499207977693184 https://twitter.com/bibryam/status/1601499207977693184 https://twitter.com/bibryam/status/1609979930351132683 https://twitter.com/bibryam/status/1609979930351132683
  - Given_47 3y ago
    For posterity here’s [1] a list of Nitter instances. The flagship one (Nitter.net) always gets overloaded [1]: https://github.com/zedeus/nitter/wiki/Instances https://github.com/zedeus/nitter/wiki/Instances
- tempest_ 3y ago
  Honestly the picture shown in that thread are fine and most people I have met grok those commands really quick. The issue is git's interface is terrible and very powerful. Which means when something goes awry and they land outside those 5 or 6 commands they often have no idea how to fix it. Which invariably leads to a copy paste of their changes and a delete and re-clone. Honestly I really like mercurial. I found its interface better but in this day and age all the tooling is built around git so ...
forrestthewoods 3y ago
My dream is that someday we’ll all use a VCS that is so simple the internet doesn’t have literally tens of thousands of blog posts pretending it’s simple. Someday…
- Espressosaurus 3y ago
  We had our chance and decided that worse is better, so here we are.
  - IshKebab 3y ago
    Mercurial was simpler but it was also written in slooooow Python so overall it wasn't really better.
    - forrestthewoods 3y ago
      Re-implementing a good API in a better language is relatively easy. Replacing a bad API is nigh impossible. :( Mistakes were made.
      - memefrog 3y ago
        It is easy to replace a "bad API". There are a million alternative CLIs and GUIs for git. They haven't caught on because it turns out git's CLI isnt actually bad. It feels complex because it feels like what it is doing is simpler than is presented. But in fact it is solving quite a complicated distributed database program, transactionally, with editable history. The CLI hides a lot of that but cant hide it all. But you do need the flexibility.
        forrestthewoods 3y ago
        Hard disagree. Perforce is idiot proof. I can teach a non-programmer who has never even heard of revision control how to use Perforce in literally 10 minutes. They will never shoot themselves in the foot. They will never lose work. They will never, ever need to nuke and reclone their repo. Perforce has other issues of course. But Git has both a bad CLI and a bad model. Maybe its particular model is strictly required for the Linux kernel. However for 99% of developers that are centralized on GitHub the model ranges from “mediocre fit” to “downright broken”.
smokel 3y ago
How can it be that we are still using plain text files for editing code? Wouldn't the grass be greener if a variable were stored as a unique key, making refactoring trivial? Wouldn't the birds sing louder if formatting were just a view on the underlying data? And wouldn't the sun shine really brightly if diffs were to operate directly on the abstract syntax tree? I fear that this has to do with the great problem of interoperability, and of people not always wanting to work together. What would be a constructive way to coordinate ourselves out of this silliness?
- zakary 3y ago
  Those do sound like good ideas. Why don’t you try making a proof of concept? I’d definitely give it a go
- PlunderBunny 3y ago
  Not to mention that comments could point to bits of code without being in the code. We could show them to the user like tooltips (or like the sweet sweet balloon help from macOS Classic - how I miss it so much!)
- suralind 3y ago
  You may be interested in difftastic for doing diffs based on the AST. One problem with this approach is that when you have a lot of changes (tens of lines, maybe hundreds), it gets slow. The tool is great thou, and is my default diffing tool.
  - eviks 3y ago
    Great potential tool especially when it adds structured data output for easier integration with other tools
  - erik_seaberg 3y ago
    We need a way to not break the AST when we extend the language.
- OkayPhysicist 3y ago
jasoneckert 3y ago
Not a bad guide, but the Linux/Windows differentiation is a bit deceiving. For example, 'git config --global user.name "username"' and 'git config --global user.email "useremail"' are required for Git users on any system before a commit is made, but since it follows the 'Git Configuration: Windows' title, it reads as if it's a Windows-specific configuration. Additionally, $HOME/.gitconfig is also used by Linux (and UNIX and macOS) systems to store this configuration.
noiv 3y ago
I like the guide, but that simply scrolling the page adds entries to the browser's history makes me cry.
- noddingham 3y ago
  Agreed that is awful
- suralind 3y ago
  The scrolling is indeed terrible.
- everybodyknows 3y ago
  Expected better from Redhat -- looks like incompetence.
loubbrad 3y ago
Leaving this here (not self promo): https://www.youtube.com/watch?v=hZS96dwKvt0 https://www.youtube.com/watch?v=hZS96dwKvt0 By far the best non-beginner git tutorial I've ever found.
LargeTomato 3y ago
Honestly Redhat puts out some really solid documentation and blog posts. It's a shame what they're doing with rhel.
karmakaze 3y ago
OT: scrolling creates browser history entries that have to be skipped back, back, etc to go back--new ways to break user expectations.
725686 3y ago
I always recommend getting started with git with "Git For Ages 4 And Up" by Michael G. Shwern: https://www.youtube.com/watch?v=1ffBJ4sVUb4&t=10s https://www.youtube.com/watch?v=1ffBJ4sVUb4&t=10s
spiritplumber 3y ago
Stupid question: how do I move stuff from "master" to, IDK, "main" or similar, while preserving history?
- yCombLinks 3y ago
  Cherry pick if you want an entire commit
mlsu 3y ago
Git is one of those things that people (including myself) have frequently derided for being "unintuitive", "full of footguns", etc. But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies. Any tool that deals with collaborative working on document will present the same issues that Git does. Maybe worse. Be thankful that you can use any tool you want to create plain-text diffs; that git performs operations quickly; that resets, undo's, etc are possible; that the precise history (both of the actual state and the steps taken to get there) is entirely legible; that each command performs a single, well-defined, and well documented atomic operation; that the tool is extensible, command-line script-able, usable locally, free; that it keeps the size of a repository small; that it is scalable across any number of contributors working simultaneously. Some, all, or none of these may be true with other tools. Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it.
- paulddraper 3y ago
  Yes and no. Git beautifully matches the problem of collaboration at a fundamental level. The abstractions, the data structures... if not flawless then at least very, very good. (And that is enough to overcome any number of other issues.) The complaints are the inconsistency of the interface. E.g. `git branch`
  - mlsu 3y ago
    Yes, But I would say that is a minor issue; I appreciate that there actually is lots of documentation for the precise and unchanging behavior of `git branch`! Instead of: "Oh, email this to doc management. Depends on who you get. If you get Nancy, she will double check that your rev C filename matches with your rev D filename in the changes section. Matteo does it differently though, sometimes you do need to include redlines for minor AND major changes, even if the major version gets rev'd. Oh, that doc doesn't have any minor changes at all. I don't really know why, but you better not include minor changes because that will be flagged for sure, only on this document though, for every other one you should have C->D in the footer. Oh that one, the template never got updated so you actually have to type it in manually. Yeah, no idea why it does that. It would be great if you got the change review back by Wednesday because regulatory has a preliminary product summative scheduled Monday. There's a confluence page for which doc manager should be CC'd for each document to get the review back in time."
seba_dos1 3y ago
Teaching git by showing commands is like teaching how to write letters by showing LibreOffice Writer's toolbars. It only makes sense when you're moving from another similar DVCS that you already understand and know what you're operating on by using it.
Tommstein 3y ago
I am reminded of this thread I came across when Bram Moolenaar died the other day: https://groups.google.com/g/vim_dev/c/ivkq22t3LQM https://groups.google.com/g/vim_dev/c/ivkq22t3LQM . Choice quotes: > It will be good if someone can suggest the git commands for that. > I tried creating diffs from the tagged commits, but those are a bit messy too. I'll not try to fix more, unless someone can tell me the git commands that will make something better. Consider that even the creator of Vim, a text editor so esoteric that the running joke is that no one even knows how to exit it at first, was repeatedly asking for help with Git commands. Let that sink in.
- PlunderBunny 3y ago
  My version of this is: "Tell me which button to smash to make this problem go away."
eviks 3y ago
Beginners should use a good GUI client that would obviate the need to remember a whole bunch of commands in the guide while also being more expressive
Pxtl 3y ago
Unrelated to content of article but the fact that scrolling the article pushes sections onto the history stack (instead of replacing the top of the stack) is exceptionally rude. I should not have to hit back 10 times just because I skimmed through the subject headings.
PaulDavisThe1st 3y ago
Someone might appreciate the write-up I did after using git for a couple of years: https://ardour.org/files/gitintro.pdf https://ardour.org/files/gitintro.pdf If I say so myself, I think it's better than TFA from redhat.
- whartung 3y ago
  This was a nice document. But could you expand what happens after step 4 of your last workflow if you get a conflict with the rebase? You say: > and then tell git to continue attempting to apply your changes. Sorry, I just don’t know what that means. Redo step 4? Does rebase fail on the first conflict? It seems that when you get a rebase conflict your in the middle of a process but dumped to the command line. It’s not clear how you move forward (I guess repeat step 4) but more importantly how do you go back to the start before you did step 4?
  - PaulDavisThe1st 3y ago
    so, you run git rebase master and get a conflict report. You fire up your preferred editor/IDE/whatever on the files that have conflicts, and you fix the conflicts, either by picking one of the versions (they will be marked sections delimited by <<<< and >>>>) or by manually merging the versions into a single new version. You save those files back to disk. Then you run git add ... list of files with conflicts that are now fixed ... and then you run git rebase continue You may have to repeat this process multiple times before the rebase can complete.
arkj 3y ago
>> When using the git commit command, we recommend always including two arguments: -an and -m. This advice will mislead beginners for whom the article is written.
542458 3y ago
On the topic of Git, I vaguely remember somebody mentioning that Google was looking at wrapping Git with something else to simplify it. Anybody remember what that project is?
- resonious 3y ago
  There's "jj", which started as a Google employee's hobby project but they put him full time on it. Not sure how much G plans to push this, but they are endorsing it at least. https://github.com/martinvonz/jj https://github.com/martinvonz/jj I've been using it myself lately and it's pretty cool. Takes some getting used to, but actually pretty easy to recover from screw ups, unlike git.
  - 542458 3y ago
    Thank you!
hmble 3y ago
Thank you for sharing this. It inspired me to not worry about whether content already exists or not, we can surely write once again in our way again. Earlier than this post, my thought was that "What value can I add by writing about git? Theres already tons of articles for that." Seeing this post from Redhat, motivated me to write whatever I feel like writing, even if it has been written before. Thank You
ciberado 3y ago
I have contradictory feelings regarding git. For more than ten years, I was using it daily without really understanding the internals... and I was often confused and frustrated. After investing some time learning how the Directed Acyclic Graph works, suddenly everything made much more sense. And, yes: it is good to learn the underlying fundamentals of the technology we are using. But, on the other hand, it denotes a rather poor abstraction from the UX point of view, imho. Now, when I deliver git training, I start by explaining the DAG and how there is no magic, only git. By the way, the notes and exercises of the course are in my GitHub account[1], feel free to check it out if you think it can be useful. [1] https://github.com/ciberado/git-workshop https://github.com/ciberado/git-workshop (https://ciberado.github.io/git-workshop/ https://ciberado.github.io/git-workshop/)
- not_your_vase 3y ago
  Unfortunately knowing DAG's inside out will not save anyone who decides to open man git and related pages. Git is not magic. It's just the dictionary example of what you get when software developers start coding without adult supervision. Lots of cool stuff, but usability and user-friendliness is not one them.
  - ciberado 3y ago
    I only partially agree. Git is a complex project, developed to help with the management of the Linux kernel source code. Because of that, the original audience was technically very advanced and maybe didn't need any higher layer of abstraction, nor a proper product development roadmap. The problem appeared when people like I started basing our workflow on it ^_^. There are a few good books[1] and tutorials[2] out there, but I totally agree that the official documentation is only useful as a technical reference. [1] Mastering Git, https://www.packtpub.com/product/mastering-git/9781783553754 https://www.packtpub.com/product/mastering-git/9781783553754 [2] Atlassian Git tutorials, https://www.atlassian.com/git/tutorials https://www.atlassian.com/git/tutorials
  - dogleash 3y ago
    > It's just the dictionary example of what you get when software developers start coding without adult supervision. git was originally explicitly a VCS core for anyone to build on. Remember the "plumbing vs porcelain" days? I do. And after 18 years what have the "adults" done in the meantime? Come at them sideways for having the gall to release an unrefined tool that got popular?
h1fra 3y ago
In my 10 years of using Git I think I have used mostly these commands: "git pull --rebase", "git add -p", "git commit -m" and "git push" Everything else can be googled/learned when needed. I think I just wish the default flags were more sane and command's name would be less "internal".
paradite 3y ago
I use a lot of git aliases, and I check git status all the time. $ history 1000 | cut -c 8- | sort | uniq -c | sort -nr | head -10 238 gs 73 gd 68 gcz 67 ga . 56 npm run test 53 gp 29 code . 25 open . 24 git pull 20 ls
sireat 3y ago
Coming from subversion it seemed silly that staging and committing is separated in git. Why not have a command to combine the both? Most git clients handle this automatically since for most "normal" flows there is no need to separate the two. An explanation on the need for separate staging would be nice to include the in the philosophy of git.

277 points by freedude 3y ago

I think this is a good guide. Git tends to be an emotional topic for a lot of people - myself included - and the hill I dramatically die on time and time again is that I think, tragically, this is about where developers stop learning git. I think operations like rebase, cherrypick, and squash are just as important as some of the ones you first encounter. Especially when you're working with other people. I use them every day and I see some of the spaghetti experienced developers pile on the graph because they only know merge. I guess my point is "don't sleep on rebasing" :)

jkubicek 3y ago
Git is one of those tools that exposes so much of the underlying infrastructure that people just can't help diving in and making their own lives so much more difficult. After using git for well over a decade, I'm completely convinced that if you find yourself frequently rebasing/cherry-picking/reflogging you're using git wrong.
- hughesjj 3y ago
  .... Why not rebase before merging into main?
  - entangledqubit 3y ago
    I'm a big fan of that practice but I get the impression that rebasing scares a lot of devs that either didn't take the time to learn git or are still recovering from that one time that their change got too far away from mainline. That latter reason is why I prefer the practice actually...
    - nerdponx 3y ago
      Or they were taught Git the wrong way, by memorizing a bunch of commands, as in TFA.
    - hughesjj 3y ago
      When in doubt, git diff main>~/patch.out (... && Git checkout main && git pull --rebase && git checkout -B clean_branch && git apply ~/patch.out) (I like the light rhyming of the first part)
  - jkubicek 3y ago
    Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts, with the added bonus that rebasing can sometimes force you to resolve conflicts for each commit in your branch. Here's how I think everyone should use git: 1. Create a new branch for your changes 2. Make commits and merge from main with wild abandon 3. One final merge from main 4. Squash everything into a single commit, push a PR If you keep your branch focused on only a single change, the end result is a tight, focused, single commit PR that merges cleanly into main and didn't involve any complex or error-prone shenanigans.
    - skeeter2020 3y ago
      This is a very common workflow for larger OS projects, and I think it translates really well to corporate environments too. It reinforces some work/feature discipline and gives you a nice clean history.
    - crispyambulance 3y ago
      This is how I do it. Almost never touch rebase. Also, I hate git :-)
      - jkubicek 3y ago
        I love git, but I also never touch rebase. It's there when I need it, but I also work in such a way to never need it.
    - hughesjj 3y ago
      So, I get the "squash your feature branch into a single commit before merging upstream", but what does doing "git merge main" instead of "git rebase -i main" give you? (Assume I have my global git config to remember conflict resolutions via rerere)
    - seba_dos1 3y ago
      > Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts The opposite is true: resolving a conflict during a rebase is much easier, as you get to resolve the conflict in the context of a single commit and its parent. In some cases it may end up being more work than resolving a whole merge, but it's much easier to reason about.
- nerdponx 3y ago
  I've been using Git for the same length of time, but I have not reached this conclusion. That's the problem with teaching someone how to use a very powerful flexible tool that accommodates a variety of workflows and styles: different people use it differently.
- RandallBrown 3y ago
  I use rebase multiple times per day. Mostly for putting my changes on top of the latest development branch, but also for squashing commits. I'm curious why you don't like it?
  - jkubicek 3y ago
    My branches are always focused on a single atomic change†, so if I want the tip of my branch to be up-to-date with main (or the dev branch or whatever), merging from that branch accomplishes the same thing with a lower likelihood of conflicts. I always squash‡ before pushing a PR, so the end result is identical to a carefully rebased PR. † occasionally branches will need to be split into separate commits, but that's not my default working style ‡ I know `squash` is a rebase under the hood, but it won't ever result in conflicts, so I'm happy to use it with every PR
    - nordsieck 3y ago
      I think you'd get a lot less pushback if you mentioned that you squash every branch before merging in your original comment. That actually seems like a pretty good policy if you can keep your branches relatively small.
  - recursive 3y ago
    How/why do you use rebase for squashing?
    - seba_dos1 3y ago
      Rebase is pretty much just an automation for cherry-picking and squashing, and interactive rebase is the primary and most convenient way to put the branch you have worked on into shape before presenting it to someone else. When I hear about people not using rebase in their daily workflow, I imagine myself 10 years ago when I barely knew git and couldn't really use it as a helpful tool like I do today. It's almost like looking back to before I started using VCS in the first place - somehow I did manage to not use one for years (even collaborated via FTP!), but now it seems impossible. Usually most of the useful magic with git happens before anything gets pushed out, and `git rebase` has a huge part in it.
- Espressosaurus 3y ago
  I agree that if you're having to use the reflog frequently, you're using git wrong (not least of which because the reflog is not designed for readability and understanding the context where it came from). But for the rest? If you're working in a repo with more than 5 people, rebase, cherry-pick, and squash are necessary to keep your sanity. Merge nodes are awful once you get beyond more than maybe 3 developers.
  - jkubicek 3y ago
    Someone else pointed out that it's probably confusing that I didn't mention that I do religiously squash my branches before committing, so we still have multiple developers with a clean main branch and no merge commits.
  - recursive 3y ago
    I usually use reflog to answer the question "What was the name of the branch I was just working on again?" What's supposed to be wrong with that?
    - pcthrowaway 3y ago
      That's perfectly reasonable IMO. If you just need to checkout the last branch you can also `git checkout -`
    - jkubicek 3y ago
      git config --global alias.recent for-each-ref --count=20 --sort=-committerdate --format='%(committerdate:short): %(refname:short)' refs/heads/ use it like > git recent 2023-08-07: jimkubicek/add-journal-table-creator 2023-08-07: main 2023-07-28: backup/git-squash-to-main 2023-07-28: backup/cleanup
- no_wizard 3y ago
  rebase and cherry picking are both cornerstones of trunk based development workflows, and those have proven to be extremely successful in my experience, vs other methods (like Git Flow, the GitHub overly simplistic branch per feature and merge approach, which feels like trunk based but isn't etc.) rebase makes roll backs extremely easy if you need to roll back specific commits because of bugs and makes releases easier via cherry picking (so you don't slow down trunk merges just to do a release) and allow for fine grained continuous deployment that is harder to achieve than without it. It is my experience however, that either everyone needs to rebase or you end up with issues eventually when only some developers are and other ones aren't. I don't care as much for squashing myself as a general case, as you lose fine grained per commit rollback strategies though
  - nordsieck 3y ago
    > It is my experience however, that either everyone needs to rebase or you end up with issues eventually when only some developers are and other ones aren't. The only time I merge is when I'm working on a shared remote branch. I haven't found a workflow (although I'm all ears if you have any suggestions).
    - sixstringtheory 3y ago
      Here's my current workflow: 1. write some code on a local branch 2. upstream has new revisions? rebase my branch on top 3. if not finished with my task yet, go to 1 4. if ready for review, open PR 5. if accepted, squash and merge 6. if changes are requested, write more code 7. upstream got more commits causing a conflict? don't rebase! it will screw up the PR history on GitHub and can cause issues for reviewers who might've checked out your branch locally and maybe done some experiments. merge upstream into your local branch. then you can push fast-forwardable commits. 8. push new commits to PR and go to 5 I used to think of rebasing as just rewriting commit history. But now I also think of it as altering the history of collaboration that is captured in a PR. So I switched from rebasing onto new upstream base branch commits and force pushing to PRs that already had reviews, to merging in new upstream base branch changes. I only do this after someone else has done anything on my PR; if I open it but nobody has reviewed yet, I'll do the rebase/forcepush to keep it current until someone does. I prefer squashing to merge because I prefer the default branch to have one commit per unit of collaborative work. The way different people split up commits on a branch is arbitrary and varies widely; you'll never get more than 2 engineers to agree on a convention here. Keep all the messy stuff in the PR, and you can always revert one of those individual commits if you want finer-grained rollback. If you want a PR to have generated more than one commit, then it should be more than one PR.
- lcnPylGDnU4H9OF 3y ago
  > I'm completely convinced that if you find yourself frequently [cherry-picking] you're using git wrong. A previous employer had a multi-tenant application that was deployed as a client-specific application which loaded the "core" as a dependency. They didn't really know how to do versioning and most version changes were just arbitrary "I feel like we should call it 1.8 now". At one point I ended up maintaining a client-specific branch of the core dependency on version 1.10 (branch was 1.10-$CLIENT) while the "main" branch was 2.3 or something. For context, it went 1.10 to 2.0 because general cognitive dissonance. This meant any change that needed to be made in the application core for this particular client also needed to be cherry-picked in some direction, usually by making the change on the client branch and cherry-picking it back as necessary. In some cases another client -- naturally, they would be on a separate branch like 2.3-$CLIENT -- also wanted that change so it needed to be cherry-picked again to that branch. The result was a minimum of two PRs, one a cherry-pick of the others' commits (one commit unless I felt like spending my time in self-loathing), that I would make for every change. Not knocking cherry-pick at all; it's wonderfully useful when used correctly. That's just the result of non-technical decision-makers making decisions about technical tools. On the plus side, I learned a ton about git in that job.
- jsunderland323 3y ago
  If you’re doing collaborative trunk based development then you’re only cherry-picking. So far Dave Farley is the only person I’ve ever heard advocate for this but it does have its place in the universe. Cherry picking is not destructive to history fwiw. There’s absolutely nothing wrong with rebasing/squashing/amending/resetting heads on personal feature branches. In fact, it’s a pretty good practice if you make messy history and can make PRs less of an eyesore. I think the confusion comes up about when destructive history operations are appropriate because the git cli client does not have a concept of protected (shared) branches vs feature branches. As long as you keep history destructive operations away from shared branches, you’re good.
  - seba_dos1 3y ago
    In some cases, you're still good even when rewriting shared branches. At work we're maintaining a downstream Linux tree with a few hundred patches on top of mainline. The tree gets frequently rebased on top of new upstream releases, and some changes are being progressively upstreamed. It's much easier to reason about the remaining downstream changes and deal with conflicts when rebasing than when merging upstream releases back into the downstream tree. Of course you can't expect to be able to carelessly `git pull` in such workflow, but if you're working with people who actually know how to use git it's not really a big deal. Naturally, this particular project uses a special workflow that fits its needs. It doesn't usually make sense to rewrite shared branches in projects where you're the upstream.
    - deleted 3y ago
      [deleted]
  - jkubicek 3y ago
    I don't understand this: > If you’re doing collaborative trunk based development then you’re only cherry-picking. All my work is collaborative trunk based development, and I never cherry-pick. > There’s absolutely nothing wrong with rebasing/squashing/amending/resetting heads on personal feature branches. I agree that there's nothing _wrong_ with it, just that it's unnecessary. If your branches are focused on a single feature and you're always squashing your PRs to main, the cleanliness of the branch while you're working on it is unimportant.
- User23 3y ago
  I can’t imagine using VC for exploratory programming without rebase or something equivalent. I don’t want to bother writing a meaningful commit message for a change I’m probably going to throw away. I also don’t want to push a history like “WIP, WIP, works now, broke again, WIP” and that’s what it looks like at a first pass when I’m moving quickly. Instead I squash away the garbage and push out a reasonable looking chain of commits with nice descriptions.
- jayd16 3y ago
  How do you pull a critical fix across branches w/o the occasional cherry pick? What do you do instead?
- p1necone 3y ago
  As long as you never ever cherry-pick from one branch to another when the source branch is intended to eventually be actually merged (directly or indirectly) into the destination branch I think it has its use cases. If you break this rule you could be in for dealing with some atrocious merge conflicts though, so I try not to do it unless the branch I'm cherry picking from is a definite actual dead end (e.g. the change was an urgent hotfix against an old release branch and your workflow doesn't involve merging those back into main/master).
  - doix 3y ago
    Is that really an issue? When you rebase, git automatically figures out that you've cherry-picked something and will skip it. I will occasionally chery-pick something from master, do my work etc. Before making my PR, I'll rebase against master and potentially squash/reorganize my commits. When the PR eventually gets merged to master there aren't any problems. I don't think I ever merge without rebasing though, so maybe rebase has been saving me from any potential problems.
    - p1necone 3y ago
      Yeah I very rarely rebase, just autosquash PR commits into one on merge to master (and also delete the source branch to avoid similar headaches) + making sure PRs are fairly small and focused. Regular merges where commits have been cherry picked from one side to another, and then later also unmerged changes have touched those same files tend to result in a lot of spurious merge conflicts.
- u801e 3y ago
  > I'm completely convinced that if you find yourself frequently rebasing/cherry-picking/reflogging you're using git wrong. A lot of people want to use git as a checkpoint/backup system, and commits and associated changes reflect that. The rebasing/cherry-picking/reflogging is one way to update the set of commits on the branch in order to make a set of meaningful commits for the feature branch they're working on.
zwieback 3y ago
If you use those commands in your local repo to keep the central shared repo clean then yeah, rebase and friends are great.

StevenXC 3y ago

I've been working a bit the past week on a guide for a workshop I'll be running in a few months to get research mathematicians productive using just GitHub's UI. [0] So the purpose is not identical by any means. But I'm curious whether it's appropriate that this RedHat guide seems to go straight into "what commands do I run" rather than answering/illustrating "how does Git model the history of a software project's files". [0]: http://jmm2024.clontz.org/ http://jmm2024.clontz.org/

nerdponx 3y ago
The #1 mistake in trying to teach people Git is jumping right to commands without developing a mental model first. It leads to nothing but confusion down the line, and reliance on copy/paste of snippets and scripts to get anything done. Effective usage of Git depends heavily on having a basic understanding of how it works, moreso than a lot of other tools.
- IshKebab 3y ago
  Definitely a mistake, though you can explain Git's data model in about 2 minutes. I would say a bigger mistake is starting with the command line. A good GUI is absolutely instrumental to understanding Git, and it lets you avoid Git's terrible CLI for as long as possible.
  - nerdponx 3y ago
    Interesting about starting with the GUI. I can see it being useful in a controlled learning environment where you start with the GUI and gradually transition to the CLI. But if you stay on the GUI too long the student might suffer because they eventually will need to use the CLI, or at least understand its vocabulary, in order to read the documentation and get help from other people.
  - memefrog 3y ago
    I totally disagree. GUIs inevitably confuse people about git. I have never met anyone that used a GUI for git that actually understood it.

chiefalchemist 3y ago

This guide would benefit from some visuals. That is, what is happening, and why. Else, for beginners, just listing commands is too abstract. It would also help to elaborate a bit on why, or at least walk though a merge conflict, 'cause ultimately, that's what beginners need to be aware of. That is, Dev A made changes a file and Dev B also made changes to that file. Boom! But this is why we use Git.

nerdponx 3y ago
The Git book, Pro Git, does a decent job of this. Also https://learngitbranching.js.org/ https://learngitbranching.js.org/
- chiefalchemist 3y ago
  I believe that on GitHub there are also visual examples. For me, ultimately, Git is best understood when there are visuals. The command line is cool, but if there's a tool that begs for a UI it's Git. Yeah, I know there are Git UI tools, so many the article should have suggested some of those as well?
  - nerdponx 3y ago
    I have yet to find a Git GUI that really feels right. Recommendations?
    - chiefalchemist 3y ago
      I've been using GitKraken which is paid (@ a fair $60 p/y). But I also see FOSS options mentioned on HN from time to time and intend to explore one of those. Perhaps I'll do an Ask HN later today?

jehb 3y ago

Fun fact, when I worked at Red Hat for many years on the Opensource.com project, we created a collection of dozens of great articles on the ins and outs of git, written by open source community members. You can still find most of those articles here: https://opensource.com/tags/git https://opensource.com/tags/git Unfortunately, the team who ran site got caught up in Red Hat's layoffs earlier this year and the site has been sitting in limbo ever since, so I don't know what will happen to it long term.

pabs3 3y ago
ArchiveTeam saved the entire site to archive.org using ArchiveBot, except for the downloads, since those were loginwalled. If you are able to contact whoever still has access, it would be great to be able to save the downloads too. It looks like the team or someone from it are planning on continuing the site though? https://wiki.archiveteam.org/?title=ArchiveBot https://wiki.archiveteam.org/?title=ArchiveBot https://archive.fart.website/archivebot/viewer/domain/opensource.com https://archive.fart.website/archivebot/viewer/domain/openso... https://opensource.com/article/23/6/new-developments-opensourcecom https://opensource.com/article/23/6/new-developments-opensou...

micw 3y ago

A short explaination what remotes are and how to configure it would be helpfull. Otherwise, the "git push" command would fail and the tutorial gives no hint, why.

criddell 3y ago

This image helped me a lot: https://nitter.net/pic/orig/media%2FFjJ62xKXkAYfFjt.jpg https://nitter.net/pic/orig/media%2FFjJ62xKXkAYfFjt.jpg

nelsonfigueroa 3y ago
Wow this is great. Wish I came across something like this back when I was learning git.
boneitis 3y ago
As someone who's having a very difficult time coming to grips with git, would really appreciate another source for this. It does not load for me, in the eight ways I have tried to load it (two devices each on a different IP, on two browsers, with that %2F left encoded and attempted with it unencoded.)
- 6581 3y ago
  https://twitter.com/bibryam/status/1601499207977693184 https://twitter.com/bibryam/status/1601499207977693184 https://twitter.com/bibryam/status/1609979930351132683 https://twitter.com/bibryam/status/1609979930351132683
- Given_47 3y ago
  For posterity here’s [1] a list of Nitter instances. The flagship one (Nitter.net) always gets overloaded [1]: https://github.com/zedeus/nitter/wiki/Instances https://github.com/zedeus/nitter/wiki/Instances
tempest_ 3y ago
Honestly the picture shown in that thread are fine and most people I have met grok those commands really quick. The issue is git's interface is terrible and very powerful. Which means when something goes awry and they land outside those 5 or 6 commands they often have no idea how to fix it. Which invariably leads to a copy paste of their changes and a delete and re-clone. Honestly I really like mercurial. I found its interface better but in this day and age all the tooling is built around git so ...

forrestthewoods 3y ago

My dream is that someday we’ll all use a VCS that is so simple the internet doesn’t have literally tens of thousands of blog posts pretending it’s simple. Someday…

Espressosaurus 3y ago
We had our chance and decided that worse is better, so here we are.
- IshKebab 3y ago
  Mercurial was simpler but it was also written in slooooow Python so overall it wasn't really better.
  - forrestthewoods 3y ago
    Re-implementing a good API in a better language is relatively easy. Replacing a bad API is nigh impossible. :( Mistakes were made.
    - memefrog 3y ago
      It is easy to replace a "bad API". There are a million alternative CLIs and GUIs for git. They haven't caught on because it turns out git's CLI isnt actually bad. It feels complex because it feels like what it is doing is simpler than is presented. But in fact it is solving quite a complicated distributed database program, transactionally, with editable history. The CLI hides a lot of that but cant hide it all. But you do need the flexibility.
      - forrestthewoods 3y ago
        Hard disagree. Perforce is idiot proof. I can teach a non-programmer who has never even heard of revision control how to use Perforce in literally 10 minutes. They will never shoot themselves in the foot. They will never lose work. They will never, ever need to nuke and reclone their repo. Perforce has other issues of course. But Git has both a bad CLI and a bad model. Maybe its particular model is strictly required for the Linux kernel. However for 99% of developers that are centralized on GitHub the model ranges from “mediocre fit” to “downright broken”.

smokel 3y ago

How can it be that we are still using plain text files for editing code? Wouldn't the grass be greener if a variable were stored as a unique key, making refactoring trivial? Wouldn't the birds sing louder if formatting were just a view on the underlying data? And wouldn't the sun shine really brightly if diffs were to operate directly on the abstract syntax tree? I fear that this has to do with the great problem of interoperability, and of people not always wanting to work together. What would be a constructive way to coordinate ourselves out of this silliness?

zakary 3y ago
Those do sound like good ideas. Why don’t you try making a proof of concept? I’d definitely give it a go
PlunderBunny 3y ago
Not to mention that comments could point to bits of code without being in the code. We could show them to the user like tooltips (or like the sweet sweet balloon help from macOS Classic - how I miss it so much!)
suralind 3y ago
You may be interested in difftastic for doing diffs based on the AST. One problem with this approach is that when you have a lot of changes (tens of lines, maybe hundreds), it gets slow. The tool is great thou, and is my default diffing tool.
- eviks 3y ago
  Great potential tool especially when it adds structured data output for easier integration with other tools
- erik_seaberg 3y ago
  We need a way to not break the AST when we extend the language.
OkayPhysicist 3y ago

jasoneckert 3y ago

Not a bad guide, but the Linux/Windows differentiation is a bit deceiving. For example, 'git config --global user.name "username"' and 'git config --global user.email "useremail"' are required for Git users on any system before a commit is made, but since it follows the 'Git Configuration: Windows' title, it reads as if it's a Windows-specific configuration. Additionally, $HOME/.gitconfig is also used by Linux (and UNIX and macOS) systems to store this configuration.

noiv 3y ago

I like the guide, but that simply scrolling the page adds entries to the browser's history makes me cry.

noddingham 3y ago
Agreed that is awful
suralind 3y ago
The scrolling is indeed terrible.
everybodyknows 3y ago
Expected better from Redhat -- looks like incompetence.

loubbrad 3y ago

Leaving this here (not self promo): https://www.youtube.com/watch?v=hZS96dwKvt0 https://www.youtube.com/watch?v=hZS96dwKvt0 By far the best non-beginner git tutorial I've ever found.

LargeTomato 3y ago

Honestly Redhat puts out some really solid documentation and blog posts. It's a shame what they're doing with rhel.

karmakaze 3y ago

OT: scrolling creates browser history entries that have to be skipped back, back, etc to go back--new ways to break user expectations.

725686 3y ago

I always recommend getting started with git with "Git For Ages 4 And Up" by Michael G. Shwern: https://www.youtube.com/watch?v=1ffBJ4sVUb4&t=10s https://www.youtube.com/watch?v=1ffBJ4sVUb4&t=10s

spiritplumber 3y ago

Stupid question: how do I move stuff from "master" to, IDK, "main" or similar, while preserving history?

yCombLinks 3y ago
Cherry pick if you want an entire commit

mlsu 3y ago

Git is one of those things that people (including myself) have frequently derided for being "unintuitive", "full of footguns", etc. But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies. Any tool that deals with collaborative working on document will present the same issues that Git does. Maybe worse. Be thankful that you can use any tool you want to create plain-text diffs; that git performs operations quickly; that resets, undo's, etc are possible; that the precise history (both of the actual state and the steps taken to get there) is entirely legible; that each command performs a single, well-defined, and well documented atomic operation; that the tool is extensible, command-line script-able, usable locally, free; that it keeps the size of a repository small; that it is scalable across any number of contributors working simultaneously. Some, all, or none of these may be true with other tools. Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it.

paulddraper 3y ago
Yes and no. Git beautifully matches the problem of collaboration at a fundamental level. The abstractions, the data structures... if not flawless then at least very, very good. (And that is enough to overcome any number of other issues.) The complaints are the inconsistency of the interface. E.g. `git branch`
- mlsu 3y ago
  Yes, But I would say that is a minor issue; I appreciate that there actually is lots of documentation for the precise and unchanging behavior of `git branch`! Instead of: "Oh, email this to doc management. Depends on who you get. If you get Nancy, she will double check that your rev C filename matches with your rev D filename in the changes section. Matteo does it differently though, sometimes you do need to include redlines for minor AND major changes, even if the major version gets rev'd. Oh, that doc doesn't have any minor changes at all. I don't really know why, but you better not include minor changes because that will be flagged for sure, only on this document though, for every other one you should have C->D in the footer. Oh that one, the template never got updated so you actually have to type it in manually. Yeah, no idea why it does that. It would be great if you got the change review back by Wednesday because regulatory has a preliminary product summative scheduled Monday. There's a confluence page for which doc manager should be CC'd for each document to get the review back in time."

seba_dos1 3y ago

Teaching git by showing commands is like teaching how to write letters by showing LibreOffice Writer's toolbars. It only makes sense when you're moving from another similar DVCS that you already understand and know what you're operating on by using it.

Tommstein 3y ago

I am reminded of this thread I came across when Bram Moolenaar died the other day: https://groups.google.com/g/vim_dev/c/ivkq22t3LQM https://groups.google.com/g/vim_dev/c/ivkq22t3LQM . Choice quotes: > It will be good if someone can suggest the git commands for that. > I tried creating diffs from the tagged commits, but those are a bit messy too. I'll not try to fix more, unless someone can tell me the git commands that will make something better. Consider that even the creator of Vim, a text editor so esoteric that the running joke is that no one even knows how to exit it at first, was repeatedly asking for help with Git commands. Let that sink in.

PlunderBunny 3y ago
My version of this is: "Tell me which button to smash to make this problem go away."

eviks 3y ago

Beginners should use a good GUI client that would obviate the need to remember a whole bunch of commands in the guide while also being more expressive

Pxtl 3y ago

Unrelated to content of article but the fact that scrolling the article pushes sections onto the history stack (instead of replacing the top of the stack) is exceptionally rude. I should not have to hit back 10 times just because I skimmed through the subject headings.

PaulDavisThe1st 3y ago

Someone might appreciate the write-up I did after using git for a couple of years: https://ardour.org/files/gitintro.pdf https://ardour.org/files/gitintro.pdf If I say so myself, I think it's better than TFA from redhat.

whartung 3y ago
This was a nice document. But could you expand what happens after step 4 of your last workflow if you get a conflict with the rebase? You say: > and then tell git to continue attempting to apply your changes. Sorry, I just don’t know what that means. Redo step 4? Does rebase fail on the first conflict? It seems that when you get a rebase conflict your in the middle of a process but dumped to the command line. It’s not clear how you move forward (I guess repeat step 4) but more importantly how do you go back to the start before you did step 4?
- PaulDavisThe1st 3y ago
  so, you run git rebase master and get a conflict report. You fire up your preferred editor/IDE/whatever on the files that have conflicts, and you fix the conflicts, either by picking one of the versions (they will be marked sections delimited by <<<< and >>>>) or by manually merging the versions into a single new version. You save those files back to disk. Then you run git add ... list of files with conflicts that are now fixed ... and then you run git rebase continue You may have to repeat this process multiple times before the rebase can complete.

arkj 3y ago

>> When using the git commit command, we recommend always including two arguments: -an and -m. This advice will mislead beginners for whom the article is written.

542458 3y ago

On the topic of Git, I vaguely remember somebody mentioning that Google was looking at wrapping Git with something else to simplify it. Anybody remember what that project is?

resonious 3y ago
There's "jj", which started as a Google employee's hobby project but they put him full time on it. Not sure how much G plans to push this, but they are endorsing it at least. https://github.com/martinvonz/jj https://github.com/martinvonz/jj I've been using it myself lately and it's pretty cool. Takes some getting used to, but actually pretty easy to recover from screw ups, unlike git.
- 542458 3y ago
  Thank you!

hmble 3y ago

Thank you for sharing this. It inspired me to not worry about whether content already exists or not, we can surely write once again in our way again. Earlier than this post, my thought was that "What value can I add by writing about git? Theres already tons of articles for that." Seeing this post from Redhat, motivated me to write whatever I feel like writing, even if it has been written before. Thank You

ciberado 3y ago

I have contradictory feelings regarding git. For more than ten years, I was using it daily without really understanding the internals... and I was often confused and frustrated. After investing some time learning how the Directed Acyclic Graph works, suddenly everything made much more sense. And, yes: it is good to learn the underlying fundamentals of the technology we are using. But, on the other hand, it denotes a rather poor abstraction from the UX point of view, imho. Now, when I deliver git training, I start by explaining the DAG and how there is no magic, only git. By the way, the notes and exercises of the course are in my GitHub account[1], feel free to check it out if you think it can be useful. [1] https://github.com/ciberado/git-workshop https://github.com/ciberado/git-workshop (https://ciberado.github.io/git-workshop/ https://ciberado.github.io/git-workshop/)

not_your_vase 3y ago
Unfortunately knowing DAG's inside out will not save anyone who decides to open man git and related pages. Git is not magic. It's just the dictionary example of what you get when software developers start coding without adult supervision. Lots of cool stuff, but usability and user-friendliness is not one them.
- ciberado 3y ago
  I only partially agree. Git is a complex project, developed to help with the management of the Linux kernel source code. Because of that, the original audience was technically very advanced and maybe didn't need any higher layer of abstraction, nor a proper product development roadmap. The problem appeared when people like I started basing our workflow on it ^_^. There are a few good books[1] and tutorials[2] out there, but I totally agree that the official documentation is only useful as a technical reference. [1] Mastering Git, https://www.packtpub.com/product/mastering-git/9781783553754 https://www.packtpub.com/product/mastering-git/9781783553754 [2] Atlassian Git tutorials, https://www.atlassian.com/git/tutorials https://www.atlassian.com/git/tutorials
- dogleash 3y ago
  > It's just the dictionary example of what you get when software developers start coding without adult supervision. git was originally explicitly a VCS core for anyone to build on. Remember the "plumbing vs porcelain" days? I do. And after 18 years what have the "adults" done in the meantime? Come at them sideways for having the gall to release an unrefined tool that got popular?

h1fra 3y ago

In my 10 years of using Git I think I have used mostly these commands: "git pull --rebase", "git add -p", "git commit -m" and "git push" Everything else can be googled/learned when needed. I think I just wish the default flags were more sane and command's name would be less "internal".

paradite 3y ago

sireat 3y ago

Coming from subversion it seemed silly that staging and committing is separated in git. Why not have a command to combine the both? Most git clients handle this automatically since for most "normal" flows there is no need to separate the two. An explanation on the need for separate staging would be nice to include the in the philosophy of git.