6.3 GitHub - Vzdrževanje projekta

Nekdo pride zraven in naredi spremembe v vaši kodi in vam pošlje zahtevek potega. Morali bi dobiti e-pošto, ki vas obvesti o novem zahtevku potega in izgledati bi morali nekako kot Email notification of a new Pull Request..

Tam je nekaj stvari za opaziti o tej e-pošti. Dalo vam bo majhen status razlik (diffstat) - seznam datotek, ki so se spremenile v zahtevku potega in za koliko. Da vam povezavo na zahtevek potega na GitHub-u. Da vam tudi nekaj URL-jev, ki jih lahko uporabite iz ukazne vrstice.

Če opazite vrstico, ki pravi git pull <url> patch-1, je to enostaven način za združevanje v oddaljeno vejo brez potrebe po dodajanju daljave. Šli smo skozi to hitro v Checking Out Remote Branches. Če želite, lahko ustvarite in preklopite na tematsko vejo in nato poženete ta ukaz za združitev v spremembah zahtevka potega.

Drugi zanimivi URL-ji so .diff in .patch, ki so kot ste že ugotovili, ponujajo enoten diff in verzije popravka zahtevka potega. Tehnično bi lahko združili zahtevek potega dela z nečim takim:

Kot smo pokrili v The GitHub Flow, lahko imate sedaj pogovor z osebo, ki je odprla zahtevek potega. Lahko komentirate na določenih vrsticah kode, komentirate na celotnih pošiljanjih ali komentirate na samem celotnem zahtevku potega, povsod z uporabo GitHub Flavored Markdown-a.

Vsakič, ko nekdo drug komentira na zahtevku potega boste prejeli e-poštno obvestilo, da veste, da se dogaja aktivnost. Vsako bo imelo povezavo na zahtevek potega, kjer se aktivnost dogaja in lahko se tudi direktno odzovete na e-pošto, da komentirate na temi zahtevka potega.

Ko je enkrat koda na mestu ki ga želite in želite združiti, lahko ali potegnete kodo ali jo združite lokalno, bodisi s sintakso git pull <url> <branch>, ki smo jo videli prej ali z dodajanjem fork-a kot daljave in ujeta ter združenja.

Če je združevanje trivialno, lahko samo tudi pritisnete gumb Merge'' na strani GitHub. To bo naredilo non-fast-forward'' združitev, ustvarilo pošiljanje združitve tudi če fast-forward združevanje ni bilo možno. To pomeni, da ne glede na kaj, vsakič ko pritisnite gumb združitev, se ustvari pošiljanje združitve. Kot lahko vidite v Merge button and instructions for merging a Pull Request manually., vam GitHub da vse te informacije, če kliknete na povezavo namiga.

Če se odločite, da ga ne želite združiti, lahko tudi samo zaprete zahtevek potega in oseba, ki je to odprta bo obveščena.

If you’re dealing with a lot of Pull Requests and don’t want to add a bunch of remotes or do one time pulls every time, there is a neat trick that GitHub allows you to do. This is a bit of an advanced trick and we’ll go over the details of this a bit more in [r_refspec], but it can be pretty useful.

GitHub actually advertises the Pull Request branches for a repository as sort of pseudo-branches on the server. By default you don’t get them when you clone, but they are there in an obscured way and you can access them pretty easily.

To demonstrate this, we’re going to use a low-level command (often referred to as a `plumbing'' command, which we’ll read about more in [r_plumbing_porcelain]) called `ls-remote. This command is generally not used in day-to-day Git operations but it’s useful to show us what references are present on the server.

If we run this command against the ``blink'' repository we were using earlier, we will get a list of all the branches and tags and other references in the repository.

Of course, if you’re in your repository and you run git ls-remote origin or whatever remote you want to check, it will show you something similar to this.

If the repository is on GitHub and you have any Pull Requests that have been opened, you’ll get these references that are prefixed with refs/pull/. These are basically branches, but since they’re not under refs/heads/ you don’t get them normally when you clone or fetch from the server — the process of fetching ignores them normally.

There are two references per Pull Request - the one that ends in /head points to exactly the same commit as the last commit in the Pull Request branch. So if someone opens a Pull Request in our repository and their branch is named bug-fix and it points to commit a5a775, then in our repository we will not have a bug-fix branch (since that’s in their fork), but we will have pull/<pr#>/head that points to a5a775. This means that we can pretty easily pull down every Pull Request branch in one go without having to add a bunch of remotes.

Now, you could do something like fetching the reference directly.

This tells Git, `Connect to the `origin remote, and download the ref named refs/pull/958/head.'' Git happily obeys, and downloads everything you need to construct that ref, and puts a pointer to the commit you want under .git/FETCH_HEAD. You can follow that up with git merge FETCH_HEAD into a branch you want to test it in, but that merge commit message looks a bit weird. Also, if you’re reviewing a lot of pull requests, this gets tedious.

There’s also a way to fetch all of the pull requests, and keep them up to date whenever you connect to the remote. Open up .git/config in your favorite editor, and look for the origin remote. It should look a bit like this:

That line that begins with fetch = is a `refspec.'' It’s a way of mapping names on the remote with names in your local `.git directory. This particular one tells Git, "the things on the remote that are under refs/heads should go in my local repository under refs/remotes/origin." You can modify this section to add another refspec:

That last line tells Git, `All the refs that look like `refs/pull/123/head should be stored locally like refs/remotes/origin/pr/123.'' Now, if you save that file, and do a git fetch:

Now all of the remote pull requests are represented locally with refs that act much like tracking branches; they’re read-only, and they update when you do a fetch. This makes it super easy to try the code from a pull request locally:

The eagle-eyed among you would note the head on the end of the remote portion of the refspec. There’s also a refs/pull/#/merge ref on the GitHub side, which represents the commit that would result if you push the ``merge'' button on the site. This can allow you to test the merge before even hitting the button.

Not only can you open Pull Requests that target the main or master branch, you can actually open a Pull Request targeting any branch in the network. In fact, you can even target another Pull Request.

If you see a Pull Request that is moving in the right direction and you have an idea for a change that depends on it or you’re not sure is a good idea, or you just don’t have push access to the target branch, you can open a Pull Request directly to it.

When you go to open a Pull Request, there is a box at the top of the page that specifies which branch you’re requesting to pull to and which you’re requesting to pull from. If you hit the ``Edit'' button at the right of that box you can change not only the branches but also which fork.

Here you can fairly easily specify to merge your new branch into another Pull Request or another fork of the project.

When we mention notifications'' here with respect to GitHub, we mean a specific way that GitHub tries to get in touch with you when events happen and there are a few different ways you can configure them. If you go to the Notification center'' tab from the settings page, you can see some of the options you have.

The two choices are to get notifications over Email'' and over Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching.

If you are using a branch other than master'' as your default branch that you want people to open Pull Requests on or see by default, you can change that in your repository’s settings page under the Options'' tab.

Simply change the default branch in the dropdown and that will be the default for all major operations from then on, including which branch is checked out by default when someone clones the repository.

If you would like to transfer a project to another user or an organization in GitHub, there is a Transfer ownership'' option at the bottom of the same Options'' tab of your repository settings page that allows you to do this.

This is helpful if you are abandoning a project and someone wants to take it over, or if your project is getting bigger and want to move it into an organization.

Not only does this move the repository along with all its watchers and stars to another place, it also sets up a redirect from your URL to the new place. It will also redirect clones and fetches from Git, not just web requests.