Hacker News Reader

Comment by abhishekjha | Hacker News Reader

I am beginner so bear with me. I learnt git 2 years back and always end up using the same set of commands and never anything new which lets me work very smoothly on projects. I read a lot of blogs to understand how git works and how useful git reflog is. I was/am often confused about what is offered solely by git and github as these two are two different things. Is fork/PR/Issues native to git? I still don't have an answer.

View on HN

Git is to GitHub what e-mail is to Gmail. GitHub is a specific service that offers git hosting and some extra goodies.

As for what is part of what, anything you do with the ‘git’ command is part of git. Anything you have to do on github.com is not.

>Anything you have to do on github.com is not

Just to be clear we can create a branch on github as well as on git though I am not forced to do so on github. This maybe confusing for a beginner as both provide branching.

Yeah, I nearly said “anything you do on github.com,” but then remembered there are things you can do both ways.

Unless you install GitHub's hub and alias `git` to `hub` as suggested in the install doc—then some of what you can do in Git is GitHub specific

Forks are clones that live on GitHub, with some access control.

PRs are native to GitHub, but I can send you an email Requesting that you Pull from my remote. The Linux kernel team still emails patches I think.

Issues are a GitHub thing.

Thanks. This answers it. It looks like whenever git is introduced to someone is always through github. I think this is why most people assume a different picture of git than what it actually is. I think this demarcation between git and github must be clearly stated.

Github is just the end point where the program git pushes your code for storage and viewing.

There are plenty of other alternatives, including ones you can host yourself, the most popular that I've seen being GitLab and BitBucket.

None of those things are native to git. The command line git tool’s help options open up the git manual. It is pretty comprehensive; so if the topic is missing, it’s probably a github feature. (Also, things like ‘git checkout --help’ open up subsections of the manual)

Git is a decentralized source control system, also known as a DVCS (distributed version control system).

"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features.

>"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features.

The comment below you answered my question : PR/Issues are native to github.

I'm not sure what you mean by "PR/Issues are native to github", there are other choices for code review for self-hosted git:

https://www.gerritcodereview.com/

Incidentally Gerrit predates github.

"GitHub PRs/issues are native to GitHub". If you switch to Gerrit, the code commits themselves follow, but the PRs and issues don't. They're only on GitHub.

I wouldn't point to gerrit as an example of self-hosting git. Gerrit's "patchsets" and "change-id"s concepts, as well as the weirdo remote push refs, really turns the git experience into something... very different. It's very far from both how "normal" git commits and tracking branches workflow work, and from github/gitlab/bitbucket's pull-request/merge-request style.

How is it not a an "example of self-hosting git" when it's built on top of git?

I understand from your comment that it's not your preference but that doesn't mean its not a self hosted git solution.

Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork and ask the maintainer to pull it). Gerrit actively encourages you to rebase and rewrite (and lose) your development history in the pursuit of a "perfect" one-hot non-merge history patchset, which actively loses information about the context of where your changes where applied.

The problem with submitting a rebased branch is that while there are no apparent merge conflict and your changes appear to have been developed on the tip of master, your changes may actually have been developed on a much older version of master. Builds may appear to compile fine but they might not make sense - when you discard and rebase the context of commits, you lose important information.

Reply on news.ycombinator.com