this post was submitted on 26 May 2024
43 points (92.2% liked)

Git

2904 readers
1 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
 

I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the "distributed" mindset didn't happen overnight.

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 38 points 5 months ago (3 children)

I initially found git a bit confusing because I was familiar with mercurial first, where a "branch" is basically an attribute of a commit and every commit exists on exactly one branch. It got easier when I eventually realized that git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.

[–] canpolat 26 points 5 months ago (1 children)

git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space

Yeah, once you realize that everything falls into place.

[–] [email protected] 10 points 5 months ago

It got easier when I eventually realized that git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.

Wow, thanks. I finally understand!

[–] lysdexic 5 points 5 months ago

I initially found git a bit confusing because I was familiar with mercurial first, where a “branch” is basically an attribute of a commit and every commit exists on exactly one branch.

To be fair, Mercurial has some poor design choices which leads to a very different mental model of how things are expected to operate in Git. For starters, basic features such as stashing local changes were an afterthought that you had to install a plugin to serve as a stopgap solution.

[–] [email protected] 24 points 5 months ago* (last edited 5 months ago) (3 children)

That other people would care as much for a clean history like I do. Specifically, opening branches and leaving them open forever without merging them back into main, many useless commits rather than squashing or amending, or making branches-of-branches-of-branches. Drives me nuts

[–] [email protected] 14 points 5 months ago (4 children)

Omg so this. Also merging main branches into feature branches instead of rebasing.

load more comments (4 replies)
[–] [email protected] 4 points 5 months ago (1 children)

In many providers it’s possible to set up an automatic squash policy when merging to main. At our company the git history is just linear with well defined commits.

[–] [email protected] 5 points 5 months ago (8 children)

I don't think this is necessarily better. Some branches/projects are big enough that there are meaningful commits that should be made inside the project.

[–] FizzyOrange 2 points 5 months ago (5 children)

Yeah I agree but in my experience developers seem to struggle with "keep important things in history; squash unimportant things". An open "merges allowed" policy leads to people unthinkingly merging branches with 50 "typo", "fix" commits for a 100 line change.

Dunno what the answer is there.

load more comments (5 replies)
load more comments (7 replies)
load more comments (1 replies)
[–] RonSijm 18 points 5 months ago (2 children)

I think a common misconception is that there's a "right way to do git" - for example: "we must use Gitflow, that's the way to do it".

There are no strict rules for how you should use git, it's just a tool, with some guidelines what would probably work best in certain scenarios. And it's fine diverge from those guidelines, add or remove some extra steps depending on what kinda project or team-structure you're working in.

If you're new to Git, you probably shouldn't just lookup Gitflow, structure your branches like that, and stick strictly to it. It's gonna be a bit of trial-and-error and altering the flow to create a setup that works best

[–] [email protected] 4 points 5 months ago (1 children)
git add .
git commit -a
git push
[–] [email protected] 4 points 5 months ago (1 children)

At that point you might as well add an alias that does all these three things.

[–] SpeakinTelnet 5 points 5 months ago

alias fuckit="git add . && git commit -a && git push -f"

[–] lysdexic 2 points 5 months ago (1 children)

I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.

I don't think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it's a trait of Git is like complaining that Java is hard because you need to use camelCase.

Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.

[–] RonSijm 2 points 5 months ago

Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used "gitflow" as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.

But there's nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you're using it and it seems more practical to adapt the flow for your own use-case, don't worry it'd be considered wrong to not stick strictly to it

[–] [email protected] 17 points 5 months ago (13 children)

That given its popularity it would be more user friendly. Every good dev tool will have its internals or more advanced features. Git is no different. But it sure feels like it never took the idea of a polished user experience seriously. Which is fine. It’s a dev tool after all. But the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.

[–] [email protected] 13 points 5 months ago (2 children)

the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.

I don't think this is true.

Git is ugly and functional.

People love to complain about it being ugly, but it does what it's meant to. If there was actually a persistent productivity hit from its interface, one of the weird wrappers would have taken off, and replaced it.

But the truth is, those wrappers all seem to be written by people learning to use git in the first place, and just get abandoned once they get used to it.

[–] lysdexic 10 points 5 months ago

Git is ugly and functional.

I don't even think it's ugly. It just works and is intuitive if you bother to understand what you're doing.

I think some vocal critics are just expressing frustration they don't "get" a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first "why" they come across, they start to blame the tool.

load more comments (1 replies)
[–] namingthingsiseasy 5 points 5 months ago (1 children)

there has to have been a significant global productivity cost due to the lack of a better UI.

I'm not so sure about this to be honest. If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it's a bit of an overblown issue.

[–] [email protected] 3 points 5 months ago (4 children)

If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.

As I said in another reply ... how many GUIs and text editor plugins are there for git and how many use them?

What other CLI tool has as much work put into GUIs, wrappers and plugins that do not try to replace the underlying tool/CLI, even accounting for popularity?

load more comments (4 replies)
[–] [email protected] 2 points 5 months ago (1 children)

Probably important to remember that Git was designed by Linus Torvalds, the same dude who developed the Linux kernel, and who is infamous for going off on big rage-fueled rants when questioned about his methods. So yeah, it’s going to be clunky and obtuse.

load more comments (1 replies)
load more comments (10 replies)
[–] namingthingsiseasy 10 points 5 months ago (1 children)

Git's internals are very easy to understand and once you know more about them, you'll have a much better idea of how it works (especially when it comes to tags and branches). They're so simple, you could even easily write your own scripts to parse git's internal data directory if you wanted to.

I would highly recommend reading about them: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#

[–] FizzyOrange 2 points 5 months ago

They're not that simple because of packfiles. But yeah loose files are very simple. Also the documentation for packfiles is pretty bad. You end up reading other people's random notes and the Git source code. (I actually have written a Git client from scratch.)

[–] [email protected] 9 points 5 months ago (1 children)

All I will need is push, pull, and commit.

[–] tatterdemalion 5 points 5 months ago (2 children)

Sure if you never branch, which is a severely limited way of using git.

[–] [email protected] 3 points 5 months ago

Network engineer doing netdevops. branches don't work like software, always commit to main.

load more comments (1 replies)
[–] [email protected] 6 points 5 months ago (1 children)

Coming from SVN and Mercurial where commits are increasing integers, I thought the SHA-1 stuff would be a PITA. It’s not and no one cares about numbers anymore.

load more comments (1 replies)
[–] [email protected] 6 points 5 months ago

I expected any operation involving origin/foobar to be an online operation and work against the latest server-side version of the branch.

I didn’t expect it to keep a local copy of the remote branch instead.

[–] [email protected] 5 points 5 months ago

That it’s just like subversion but distributed. Both of those assumptions are wrong. It uses a lot of the same terminology as subversion, but most of the terms are conceptually different in sometimes major ways. It’s not really distributed unless you go out of your way to make it so. Most implementations use a single remote to sync back to on a regular basis. It is, however, really good about keeping changes in sequence locally until it can sync, something you can’t really do in subversion.

[–] [email protected] 2 points 5 months ago

I thought it would be hard to use and confusing all the time.

[–] [email protected] 2 points 5 months ago

I don’t actually remember when I first learned Git. Maybe it was in a university lecture. I think my biggest struggles was learning how to resolve merge conflicts properly and efficient use of branching, but I never found any of the commands difficult to understand.

load more comments
view more: next ›