My 12-year old questioned why a 'pull request' is named the way it is. Obviously it's after the command 'git pull' which fetches the latest changes, then merges them, but it's confusing according to him, and should be called a 'merge request' instead. I don't disagree.
I quote
> Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.
GitLab, on the other hand, _does_ call it "merge requests" because you to your 12-year old's point, that is what they are.
I think git made a mistake in making pull the default (fetch+explicit merge is better) but "pull request" is correct terminology.
I «never» pull and I don’t have to change any settings.
Linus talks about this in a great panel he did at Google 14 years ago: https://youtu.be/4XpnKHJAok8
(I agree that merge requests is a much better name.)
Of course we immediately centralized around GitHub and turned it into a glorified SVN but that’s the fate of all decentralized entities.
Github tends to work with forks - where each developer is working in their own fork. When the work in the fork is complete, since it is a different repository than the original one, in order to integrate the changes the command to invoke is git pull.
The difference reflects how the typical developer works with integrating changes on that hosting solution.
Engineers start to think out loud about it, mention github and gitlab, etc etc so I got a meta-level scan of their experience (or the lack of it) with these tools.
Of course this was just a warmup (or cool down) question before (or after) the real git/engineering related questions.
I'm not entirely certain about the history of the term "pull request" as it pertains to Github, but git itself has a subcommand called request-pull that will provide information about changes between two commits, where it can be fetched from, and a short log (a list of commit titles grouped by author), as well as the overall diff.
Speaking of merge, I'm a git user since ~2010, submodules, interactive rebase, filter-branch, sure, they are simple from a graph perspective, but I still don't fully understand how git knows which diffs to pull up during merge conflict... :D ... and now reading the answers here, it seems when it does the merge it uses the graph only to find the merge-base, and then it's just 3-way merge, which doesn't really map to individual commits. (And because the 3way diff looks at the raw text this means during the merge the branches are "squashed" into 1-1 commits both on top of the common base.)
Where did all you guys learn how to use GitHub?
I learnt how to use Git by picking up the basics, then whenever I needed to do anything new or whenever something didn’t make sense, I read about how that part of Git worked. Also, I read the Pro Git book, which is free and linked to from the Git homepage. If all you ever do is look for a quick fix or use a cheat sheet when something doesn’t make sense, you’re the “One year of experience ten times” developer, so try not to do that.
Learning how GitHub works after you understand Git is easy.
Manpages available on your local system, or they're online here:
https://git-scm.com/docs/gittutorial
Jokes aside, there is a wealth of literature on how to understand git from the ground up. I strongly recommend reading through one of those. I can't recommend anything in particular, but I'm sure someone else will chime in with their favourite.
Since you asked, I just published Head First Git. I did a "Show HN" that didn't get much traction, but rather than repeating what I said there, I'll just post the link—https://news.ycombinator.com/item?id=30072348
[end shameless plug]
And to the point many others made, there are a _lot_ of resources out there, but if you are looking to start back at the basics, I feel my book (which is designed for beginners) might be a good start.
Of course there is the canonical Pro Git (https://git-scm.com/book/en/v2) book.
And once you understand the _Directed Acyclic Graph_ I feel https://github.com/git-school/visualizing-git is a great project to see what happens when you run certain operations in Git.
Perhaps you've concluded that I love Git, and I love teaching it—I am @looselytyped on Twitter (DMs are open) if you want to reach out and we can carry out a conversation elsewhere—always willing to talk Git.
Edit—I replied to the wrong comment. My apologies kqr. This was meant for VeninVidiaVicii.
The way I built an understanding of git was to create a local git repo, and start working with some plain text files. I tried the various commands - add, commit, branch, merge, and observed what happened to each file. Take this a step further and start working with a remote - you can use github.
This is how I built a mental model of what git and its commands do.
It is, however, necessary to have a mental model of what your source control system actually does above the covers, and how to use it. It is important to know that you have a staging area and a local repo and a remote/upstream repo. It is important to know that each commit has a parent commit (or occasionally two or more parents). It’s important to know where your commits go, how to put them there, and how to get them back later.
Whoever made this: Good work!
In that the image works equally well as elegance for some, and criticism for others.
Click or tap the backgrounds or the arrows.
https://www.youtube.com/watch?v=2sjqTHE0zok (MIT OpenCourseWare, Missing Semester).
1h25mn well spent
