Git Tutorial - Revision history

BAILOPAN at 17:00, 6 May 2014

2014-05-06T17:00:58Z

BAILOPAN at 16:58, 6 May 2014

2014-05-06T16:58:29Z

BAILOPAN at 07:00, 22 March 2014

2014-03-22T07:00:29Z

BAILOPAN at 06:59, 22 March 2014

2014-03-22T06:59:52Z

BAILOPAN at 06:42, 22 March 2014

2014-03-22T06:42:30Z

BAILOPAN at 06:42, 22 March 2014

2014-03-22T06:42:11Z

BAILOPAN at 04:00, 13 February 2014

2014-02-13T04:00:55Z

BAILOPAN at 20:22, 11 February 2014

2014-02-11T20:22:22Z

BAILOPAN at 17:42, 11 February 2014

2014-02-11T17:42:28Z

DS: /* Tips and Tricks */ BC has nothing to do with water!

2014-02-11T09:10:47Z

‎Tips and Tricks: BC has nothing to do with water!

@@ Line 26: / Line 26: @@
 <pre>
 git clone https://USER@github.com/alliedmodders/repository
 </pre>

@@ Line 1: / Line 1: @@
-AlliedModders now hosts some of its repositories on Git, at: [https://labs.alliedmods.net/ https://labs.alliedmods.net/]
+AlliedModders now hosts some of its repositories on Git, via GitHub. There are two ways you can browse these repositories:
 =Getting Started=
@@ Line 12: / Line 14: @@
 *You resolve repository differences by '''merging'''.
-AlliedModders uses GitLab for repository hosting and code review. GitLab allows you to "fork" a repository, which gives you your own hosted copy where you have write access. After forking a project, you can make changes, then submit a "merge request" for the original developer to accept them back. For Git projects, we use this workflow instead of patches.
+AlliedModders uses GitHub for repository hosting and code review. GitHub allows you to "fork" a repository, which gives you your own hosted copy where you have write access. After forking a project, you can make changes, then submit a "pull request" for the original developer to accept them back. For Git projects, we use this workflow instead of patches.
 ==Installing==
-See [https://help.github.com/articles/set-up-git this article] for how to install and setup Git. If you intend to send Merge Requests, you should read the section about authentication. AlliedModders supports both SSH authentication (via git.alliedmods.net) and HTTPS authentication (via labs.alliedmods.net).
+See [https://help.github.com/articles/set-up-git this article] on GitHub for how to install and setup Git. If you intend to send Pull Requests over GitHub, you should set your username and password as described.
 ==Getting Code==
-If you have either forked an AlliedModders project on GitLab, or you are a developer with write-access to one of our repositories, you should clone a repository like so:
+If you have either forked an AlliedModders project on GitHub, or you are a developer with write-access to one of our repositories, you should clone a repository like so:
 <pre>
-git clone https://USER@labs.alliedmods.net/am/repository
+git clone https://USER@github.com/alliedmodders/repository
 </pre>
-Substitute your forum username for USER, and if you're cloning a fork, the path to your fork rather than the upstream repository.
+Substitute your '''GitHub username''' for USER, and if you're cloning a fork, the path to your fork rather than the upstream repository.
-If you just want read-only access, you can use:
+If you just want read-only access, you can use one of the following URL forms:
-<pre>
+Note that <tt>git.alliedmods.net</tt> is a read-only mirror of our GitHub repositories.
 =Workflow=
-Code reviews and patch submission should take place on GitLab. Bug reporting and issue tracking, if needed, should still occur on [https://bugs.alliedmods.net/ Bugzilla]. Most of the time, you will not need to use Bugzilla. If you just want code reviewed and checked in, you can use GitLab.
+Code reviews and patch submission should take place on GitHub. Bug reporting and issue tracking, if needed, should still occur on [https://bugs.alliedmods.net/ Bugzilla]. Most of the time, you will not need to use Bugzilla. If you just want code reviewed and checked in, you can use GitHub.
 With Git, all work is usually done in ''branches''. A branch is a separate line of development that exists alongside main development. Branches have their own commit history, and can be merged back to the main line of development (called '''master'''). Branches can be deleted or shared. The crux of the Git workflow is as follows:
@@ Line 49: / Line 53: @@
 ==Contributing via Forks==
-This is the default workflow. GitLab can host personal copies of other repositories for you, called "forks". To fork a project, log in to [https://labs.alliedmods.net/ labs], then visit the project's page. For example, AMX Mod X is at [https://labs.alliedmods.net/am/amxmodx https://labs.alliedmods.net/am/amxmodx]. Just click the "Fork" button in the upper left, and you will have your own copy of the repository.
+This is the default workflow. GitHub can host personal copies of other repositories for you, called "forks". To fork a project, log in to [https://github.com/ GitHub], then visit the project's page. For example, AMX Mod X is at [https://github.com/alliedmodders/amxmodx]. Just click the "Fork" button in the upper left, and you will have your own copy of the repository.
 ===Setup===
 Once you have a fork, you can clone it and add the upstream repository as a remote source:
 <pre>
-git clone https://USER@labs.alliedmods.net/USER/amxmodx
+git clone https://USER@github.com/USER/amxmodx
-git remote add upstream https://labs.alliedmods.net/am/amxmodx
+git remote add upstream https://github.com/alliedmodders/amxmodx
 </pre>
 ===Branching===
-Whenever you are about to work on something, it's a good idea to sync your local repository to make sure it's up to date. For a more in-depth look at this, see [https://help.github.com/articles/syncing-a-fork syncing a fork]. In short, you just need to do:
+Whenever you are about to work on something, it's a good idea to sync your local repository to make sure it's up to date. For a more in-depth look at this, see [https://help.github.com/articles/syncing-a-fork syncing a fork] at GitHub. In short, you just need to do:
 <pre>
 git checkout master       # Switch to main branch
@@ Line 90: / Line 94: @@
 </pre>
-===Merge Requests===
+===Pull Requests===
-Once your branch is ready for submission, the next step is to create a merge request. First, push your branch back to Labs:
+Once your branch is ready for submission, the next step is to create a pull request. First, push your branch back to GitHub:
 <pre>
 git push origin eggapi
 </pre>
-Then, visit your dashboard on GitLab. You should see a new entry under "Recent Activity", with a "Create Merge Request" button:
+Then, visit your repository on GitHub. You should see something like:
-[[Image:Merge_request_2.PNG]]
+[[Image:Pullrequest.PNG]]
-This will send an e-mail to the development team, and a developer can then review your changes and merge them into the master branch. GitLab will then provide a button to delete your branch, and you can also remove it locally with:
+Click "Compare & pull request". This will send an e-mail to the development team, and a developer can then review your changes and merge them into the master branch. GitHub will then provide a button to delete your branch, and you can also remove it locally with:
 <pre>
@@ Line 111: / Line 111: @@
 </pre>
-Congratulations! You're done. If a developer requests changes, you can commit, and push to your branch again. Note that '''GitLab won't tell the developer that you've updated your branch'''. It's a good idea posting a comment saying that your request is ready for re-review.
+Congratulations! You're done. If a developer requests changes, you can commit, and push to your branch again. Note that '''GitHub won't tell the developer that you've updated your branch'''. It's a good idea posting a comment saying that your request is ready for re-review.
 ==Developers==
@@ Line 122: / Line 122: @@
 ===Code Review===
-Git does not change the AlliedModders policy of requiring peer review for all code changes. Unless you are fixing a broken build, all patches should be reviewed by another AlliedModders developer. Previously, this meant exporting a patch file to Bugzilla. You can still do that, but it's a very burdensome process for both developers and contributors. For Git projects we recommend the Merge Request model explained earlier.
+Git does not change the AlliedModders policy of requiring peer review for all code changes. Unless you are fixing a broken build, all patches should be reviewed by another AlliedModders developer. Previously, this meant exporting a patch file to Bugzilla. You can still do that, but it's a very burdensome process for both developers and contributors. For Git projects we recommend the Pull Request model via GitHub, explained earlier.
 *If you are submitting a pull request (PR), and you want a specific developer to review your changes: you can assign them to the PR, or just e-mail/message them the link. If they request changes, and you push new commits to the branch, the PR will update automatically. However, '''it will not send notifications'''. It's a good idea to post a comment saying that the changes are ready for re-review.
-*If you are reviewing another developer's PR, in general it's best to let them be responsible for merging it. All you have to do is review the code, and once it looks good, say something in the comments like "r=me", "ship", "+1", whatever tickles your fancy.
+*If you are reviewing another developer's PR, in general it's best to let them be responsible for merging it. All you have to do is review the code, and once it looks good, say something in the comments like "r=me", ":ship:", ":+1:", whatever tickles your fancy.
 *If you are reviewing a contributor's PR, then they won't have access to perform the merge themselves. In this case, once the code has been reviewed, you can just merge it for them.
-'''YOU HAVE THE POWER!!!!''' If you think you're qualified to review and merge a contributor's branch, go ahead! The goal of using git is to make the contribution process much more accessible, and fast response from developers is the best way, BY FAR, to keeping contributors.
+'''YOU HAVE THE POWER!!!!''' If you think you're qualified to review and merge a contributor's PR, go ahead! The goal of using GitHub is to make the contribution process much more accessible, and fast response from developers is the best way, BY FAR, to keeping contributors.
 =Mercurial Commands=
@@ Line 182: / Line 182: @@
 =SSH Authentication=
-If you have [[SSH_Keys|SSH Keys]], you can set your GitLab profile to accept them. This is '''HIGHLY RECOMMENDED''' for AlliedModders developers. You probably already have a key with us, even.
+If you have [[SSH_Keys|SSH Keys]], you can set your GitHub profile to accept them. This is '''HIGHLY RECOMMENDED''' for AlliedModders developers. You probably already have a key with us, even.
 =Tips and Tricks=

← Older revision		Revision as of 07:00, 22 March 2014
Line 1:		Line 1:
−	AlliedModders now hosts some of its repositories on Git, ~~via GitLab~~: [https://labs.alliedmods.net/ https://labs.alliedmods.net/]	+	AlliedModders now hosts some of its repositories on Git, at: [https://labs.alliedmods.net/ https://labs.alliedmods.net/]

	=Getting Started=		=Getting Started=

@@ Line 125: / Line 125: @@
 *If you are submitting a pull request (PR), and you want a specific developer to review your changes: you can assign them to the PR, or just e-mail/message them the link. If they request changes, and you push new commits to the branch, the PR will update automatically. However, '''it will not send notifications'''. It's a good idea to post a comment saying that the changes are ready for re-review.
-*If you are reviewing another developer's PR, in general it's best to let them be responsible for merging it. All you have to do is review the code, and once it looks good, say something in the comments like "r=me", ":ship:", ":+1:", whatever tickles your fancy.
+*If you are reviewing another developer's PR, in general it's best to let them be responsible for merging it. All you have to do is review the code, and once it looks good, say something in the comments like "r=me", "ship", "+1", whatever tickles your fancy.
 *If you are reviewing a contributor's PR, then they won't have access to perform the merge themselves. In this case, once the code has been reviewed, you can just merge it for them.

@@ Line 182: / Line 182: @@
 =SSH Authentication=
-If you have [[SSH_Keys|SSH Keys]], you can set your GitHub profile to accept them. This is '''HIGHLY RECOMMENDED''' for AlliedModders developers. You probably already have a key with us, even.
+If you have [[SSH_Keys|SSH Keys]], you can set your GitLab profile to accept them. This is '''HIGHLY RECOMMENDED''' for AlliedModders developers. You probably already have a key with us, even.
 =Tips and Tricks=

@@ Line 151: / Line 151: @@
 hg strip tip
 git reset --hard HEAD~1
 </pre>

@@ Line 118: / Line 118: @@
 *You can push directly to the master branch of the upstream repository. This means you can continue to use the Bugzilla workflow of exporting patches, reviewing them in the bug tracker, and then pushing them after review is complete.
 *You can merge pull requests yourself, rather than waiting on a developer.
 ===Code Review===

@@ Line 178: / Line 178: @@
 =Tips and Tricks=
-Set up a good merge tool. We really like [http://beyondcompare.com/ Beyond Compare], however, kdiff3 and meld are also good.
+Set up a good merge tool. We really like [http://scootersoftware.com/ Beyond Compare], however, kdiff3 and meld are also good.
 If you accidentally commit to master, you can copy the commit to a new branch, then erase the commit off master: