57

We have recently migrated to Git from SVN. We have setup a bare repository on one machine in our LAN network and cloned on other machines. Now when anyone do the changes and commits we want that he sends the pull request to the bare repo (by telling or emailing or any other way) after that one will go through the changes and pull it on bare repository (same as it works on GitHub).

Do we need to install any interface or there is some commands in Git itself?

Scott Weldon
  • 8,032
  • 6
  • 43
  • 60
jimy
  • 4,652
  • 3
  • 30
  • 49

3 Answers3

77

Both Git (the software) and GitHub (the web service) have a concept called "pull request", and unfortunately they are not exactly the same thing.

Native Git

The native Git request-pull command has a very short manual page with the following one-sentence description:

Summarizes the changes between two commits to the standard output, and includes the given URL in the generated summary.

This is a fairly low-level command that generates a short summary of changes that is suitable for posting to a mailing list. Other users can use the URL published in this "pull request" to manually pull changes into their own repository.

GitHub Pull Requests

When using the GitHub web service, a Pull Request is a full-featured interactive collaboration tool. A GitHub pull request has:

  • a more detailed description of the changes than just the individual commit summaries
  • notifications automatically sent to users who have chosen to watch the project
  • an online review interface where others can comment on proposed changes
  • discussion comments for recording conversations about commits
  • central management of pull requests so they won't get lost

It is worth noting that Linus has his own opinion on the relative utility of these two features.

Conclusion

The two "pull request" features described above are similar in spirit but completely different in implementation. In particular, the git request-pull command cannot be used to create a new Pull Request on GitHub. You have several choices if you want to support "pull request" type functionality:

  • Use GitHub. This definitely involves the least effort, but if your project is not public you'll have to pay GitHub to host a private repository. Some people might not be comfortable with this choice.
  • Use Gerrit. Gerrit is an open-source server program you can download that provides many features similar to those available in GitHub. It is especially well suited to collaborative code reviews.
  • Use git request-pull and a mailing list. Using this method requires a lot more discipline from your engineers, as it's easy to misplace or mishandle mailing list messages. There is no central accountability associated with this method.
Greg Hewgill
  • 828,234
  • 170
  • 1,097
  • 1,237
  • I'm not sure I understand your question. When you push to a bare repository, Git will succeed if your own repository is up to date with respect to the upstream one. If it isn't, then you will have to pull, merge, and try the push again. – Greg Hewgill Jun 04 '11 at 07:34
  • @greg i mean if somebody pushes code by mistake (no one will do it) or the bug goes in that push so cloning BARE repository will also distribute that bug. So for this purpose just want bring a layer between push or some revert option. Hope its available in GIT – jimy Jun 04 '11 at 07:49
  • 2
    I see what you mean. When that situation happens, you can create a new commit with `git revert` that undoes the change with the bug. Then you push that *new* commit. Git is very flexible, so if this is a problem with a large team, you could have developers push to an intermediate repository first. Then, an integration engineer would pull the changes from the intermediate repository, and if they test out okay, *then* push those changes to the main repository. Developers would pull from the main repository so they know they have tested working code. – Greg Hewgill Jun 04 '11 at 07:52
  • 8
    @Greg: it's not specific to Github. `git-request-pull` (http://www.kernel.org/pub/software/scm/git/docs/git-request-pull.html) is part of every Git distribution... – eckes Jun 04 '11 at 09:16
  • 3
    I have rewritten the above answer to try to address the concerns expressed by the downvotes. – Greg Hewgill Oct 26 '12 at 03:28
  • There is a github official project called hub(https://github.com/github/hub) can help you send pull request from command line. – OOO Dec 18 '13 at 03:21
  • 1
    this answer should also mention GitHub clones like Gitorious and Gitlab that copy GitHub's Pull Request interface. – strugee Oct 20 '14 at 22:16
  • also, if the problem is externalizing infrastructure (as opposed to cost), you could run GitHub:Enterprise. – strugee Oct 20 '14 at 22:17
57

The term "pull request" is not a github specific term.

There is a git request-pull command, you can read more about it here: http://linux.die.net/man/1/git-request-pull

For some more in depth explanations and save you some googling look at:

This is not a new feature BTW.

EDIT: This alternative answer was made before the originally accepted answer by @Greg Hewgill was rewritten. I posted it because this is the answer I was looking for, and I think it suited the question which asked about doing pull requests for users not necesarilly using github (Yes, not everyone using git uses github, at least not all the time). Now that the orignal answer was rewritten making this difference explicit I'll leave this answer the way I originally posted it just for the record.

Fundhor
  • 2,729
  • 1
  • 20
  • 41
Jens
  • 5,066
  • 5
  • 46
  • 64
  • 8
    Please note that GitHub does *not* use `git request-pull` either. See https://github.com/torvalds/linux/pull/17#issuecomment-5654674. –  Jun 24 '12 at 15:16
10

The "git way" of doing this would be that all the developers have their own public bare repository (read acces to all, write acces for the developer himself) on the server as their "origin". And if you like an additional "trunk" (or "stable" or whatever you want to call it) bare repo that some or all developers have write access to. The developers mirror their repo on their public repo, and pull from the other developers. That way you don't have to worry if you push something to your public repo that doesn't work yet. (The developers can just pull from you to a test branch and see if it works.) When you have a stable canonical branch you can push it to the "trunk" repo.

Stein G. Strindhaug
  • 5,036
  • 2
  • 26
  • 40
  • And implicitly that all the developers have a public server in the first place. How would that work in the era of home and mobile ISPs applying carrier-grade network address translation (CGNAT)? – Damian Yerrick Jun 05 '18 at 15:05