[HN Gopher] A beginner's guide to Git version control
___________________________________________________________________
A beginner's guide to Git version control
Author : freedude
Score : 107 points
Date : 2023-08-07 18:21 UTC (4 hours ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| smokel wrote:
| 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?
| OkayPhysicist wrote:
| We're in a very, very strong local maxima with plain text
| source code. In order for a rich-data source language to work
| you'd need to implement, competitively with what we have for
| text, the language itself (which is already a hard sell, look
| at how difficult it is for even phenomenal languages to gain a
| foothold) including built-in macro and codegen systems, a
| compiler, at least one fully-featured editor, complete with
| linting and code suggestion and search and an input mechanism
| competitive with just typing out text, possibly more than one
| to support the wide range of opinions about editors ranging
| from IDEs to Vim, source control integrated with means for
| sharing and collaborating on said code, and every other
| convenience you get for free from choosing plain text.
|
| Basically, you need to sit down and build the greatest
| programming language ever conceived, complete with a world
| class ecosystem, and then convince people that this is truly a
| revolution software development, and you probably won't make a
| dime off it because proprietary programming languages are evil.
|
| Good luck?
| PlunderBunny wrote:
| 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 wrote:
| 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.
| zakary wrote:
| Those do sound like good ideas. Why don't you try making a
| proof of concept? I'd definitely give it a go
| jdougan wrote:
| Look up "Intentional Programming", but watch out for patents.
| jasoneckert wrote:
| 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.
| StevenXC wrote:
| 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/
| gdprrrr wrote:
| Definitely mention "directed acyclic graph"
| StevenXC wrote:
| I prefer "partial order" but I'm closer to a set theorist
| than I am a combinatorist lol.
| nerdponx wrote:
| 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 wrote:
| 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.
| codetrotter wrote:
| > A good GUI is absolutely instrumental to understanding
| Git, and it lets you avoid Git's terrible CLI for as long
| as possible.
|
| Depends on the user.
|
| If they are already an active user of the Terminal, they
| should be able to learn the git cli without ever touching a
| GUI.
|
| The git cli has some warts for sure, and some weird
| inconsistencies. But with a bit of practice and some good
| documents about the correct mental model to have, you get
| used to it and you learn to use it very effectively.
| nerdponx wrote:
| 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.
| skeeter2020 wrote:
| I disagree for two reasons:
|
| 1. the git commands map so cleanly to the states 2. there
| are so many terrible GUI interfaces that try and coddle the
| developer, really hiding the intent
|
| I think the real problem is the flexibility allows for a
| lot of totally unintended but "legal" actions, from which
| it is really hard to recover _because_ it 's not your
| standard workflow.
| memefrog wrote:
| I totally disagree. GUIs inevitably confuse people about
| git. I have never met anyone that used a GUI for git that
| actually understood it.
| abdullahkhalids wrote:
| You should almost certainly talk about the way the history is
| stored. Both because it is essential to understand how git
| works, but also, if you drop in some of the mathematics that
| git uses, the mathematicians will enjoy it more.
| noiv wrote:
| I like the guide, but that simply scrolling the page adds entries
| to the browser's history makes me cry.
| noddingham wrote:
| Agreed that is awful
| suralind wrote:
| The scrolling is indeed terrible.
| LargeTomato wrote:
| Honestly Redhat puts out some really solid documentation and blog
| posts. It's a shame what they're doing with rhel.
| loubbrad wrote:
| Leaving this here (not self promo):
|
| https://www.youtube.com/watch?v=hZS96dwKvt0
|
| By far the best non-beginner git tutorial I've ever found.
| jehb wrote:
| 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
|
| 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.
| gpspake wrote:
| 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 wrote:
| 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.
| lcnPylGDnU4H9OF wrote:
| > 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.
| Espressosaurus wrote:
| 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.
| jsunderland323 wrote:
| 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.
| User23 wrote:
| 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.
| nerdponx wrote:
| 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.
| hughesjj wrote:
| .... Why not rebase before merging into main?
| jkubicek wrote:
| 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 wrote:
| 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.
| entangledqubit wrote:
| 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 wrote:
| Or they were taught Git the wrong way, by memorizing a
| bunch of commands, as in TFA.
| no_wizard wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| RandallBrown wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zwieback wrote:
| If you use those commands in your local repo to keep the
| central shared repo clean then yeah, rebase and friends are
| great.
| karmakaze wrote:
| OT: scrolling creates browser history entries that have to be
| skipped back, back, etc to go back--new ways to break user
| expectations.
| chiefalchemist wrote:
| 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 wrote:
| The Git book, Pro Git, does a decent job of this. Also
| https://learngitbranching.js.org/
| chiefalchemist wrote:
| 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 wrote:
| I have yet to find a Git GUI that really feels right.
| Recommendations?
| seba_dos1 wrote:
| * * *
| mlsu wrote:
| 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 wrote:
| 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 wrote:
| Yes. But if you don't, you should appreciate that there is
| ample documentation for `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."
| micw wrote:
| 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.
| 725686 wrote:
| 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
| criddell wrote:
| This image helped me a lot:
|
| https://nitter.net/pic/orig/media%2FFjJ62xKXkAYfFjt.jpg
| tempest_ wrote:
| 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
| ...
| messe wrote:
| It's missing: git diff > ../i-messed-up.patch
| cd .. && rm -rf $REPO git clone $REMOTE cd
| $REPO && git apply ../i-messed-up.patch
| boneitis wrote:
| 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 wrote:
| https://twitter.com/bibryam/status/1601499207977693184
|
| https://twitter.com/bibryam/status/1609979930351132683
| nelsonfigueroa wrote:
| Wow this is great. Wish I came across something like this back
| when I was learning git.
| forrestthewoods wrote:
| 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...
| IshKebab wrote:
| I think it's because it _is_ simple, but Git 's terrible CLI
| makes it hard to learn. Once you've learnt it you can ignore
| all of the terrible interface and just think about the actual
| operations you want to do which are generally very simple.
|
| I could explain Git's data model and what the operations do to
| my wife. I don't think I could actually teach her how to use
| the git command line though.
| PlunderBunny wrote:
| Yeah. Maybe I'm making excuses, but tools should be easy to use
| and get out of the way - they're not what we're being paid for.
| People say 'knowing how to use your tools properly is part of
| your craft', but I feel Git is more like someone asked for a
| cabinet and instead we gave them a hammer, some nails, and some
| timber and said 'but this is so much better than just giving
| you a cabinet!'
| Espressosaurus wrote:
| We had our chance and decided that worse is better, so here we
| are.
| IshKebab wrote:
| Mercurial was simpler but it was also written in slooooow
| Python so overall it wasn't really better.
| forrestthewoods wrote:
| Re-implementing a good API in a better language is
| relatively easy. Replacing a bad API is nigh impossible. :(
|
| Mistakes were made.
| memefrog wrote:
| 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.
| mardifoufs wrote:
| I'm curious, if you are referring to mercurial, how is it
| better?
|
| I've never used it so I'm wondering what I'm "missing out"
| on!
| memefrog wrote:
| People blog about things they learn about. Lots of people use
| git so they blog about it.
|
| Nobody is pretending it is simple. It is simple.
| forrestthewoods wrote:
| > It is simple.
|
| No, it isn't.
| spiritplumber wrote:
| Stupid question: how do I move stuff from "master" to, IDK,
| "main" or similar, while preserving history?
| yCombLinks wrote:
| Cherry pick if you want an entire commit
___________________________________________________________________
(page generated 2023-08-07 23:00 UTC)