Git and Github for Mappers - Revision history

Datiswous at 22:58, 28 November 2023

2023-11-28T22:58:19Z

← Older revision		Revision as of 22:58, 28 November 2023
Line 452:		Line 452:
	=== VS Code ===		=== VS Code ===
	=== Other Tools ===		=== Other Tools ===

			{{tutorial-editing}}

Thebigh: /* Tutorial */ -typo

2023-05-29T00:36:46Z

Tutorial: -typo

← Older revision		Revision as of 00:36, 29 May 2023
Line 65:		Line 65:
	== Tutorial ==		== Tutorial ==
	The scope of this tutorial will:		The scope of this tutorial will:
	* focus on Windows users only (although Linux ~~uses~~ can follow along just fine - Git and VS Code are available for Linux as well)		* focus on Windows users only (although Linux users can follow along just fine - Git and VS Code are available for Linux as well)
	* include the use of Visual Studio Code. The reason for using this is to demonstrate (using its Git plugin) that '''most Git interaction can be done without the use of the command line'''. If you have another preferred editor, check if it has a Git plugin and you can use that instead.		* include the use of Visual Studio Code. The reason for using this is to demonstrate (using its Git plugin) that '''most Git interaction can be done without the use of the command line'''. If you have another preferred editor, check if it has a Git plugin and you can use that instead.

Frost Salamander: /* Subsequent Beta Releases */

2023-05-13T22:07:07Z

Subsequent Beta Releases

← Older revision		Revision as of 22:07, 13 May 2023
Line 397:		Line 397:

	==== Subsequent Beta Releases ====		==== Subsequent Beta Releases ====
	This is exactly the same as the initial beta release ~~describe~~ above, except in this case you will:		This is exactly the same as the initial beta release described above, except in this case you will:
	* name the release (and tag) differently, say 'v0.2-beta' or 'v0.2'		* name the release (and tag) differently, say 'v0.2-beta' or 'v0.2'
	* When creating the release in Github, [https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes click the 'generate release notes' button]. This will auto-generate a changelog based on the pull requests that have been merged since the last tagged release. They should be categorised by label if you added the release YAML config mentioned in the setup.		* When creating the release in Github, [https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes click the 'generate release notes' button]. This will auto-generate a changelog based on the pull requests that have been merged since the last tagged release. They should be categorised by label if you added the release YAML config mentioned in the setup.

Frost Salamander: /* Use SSH for Github Authentication */

2023-05-08T09:00:29Z

Use SSH for Github Authentication

← Older revision		Revision as of 09:00, 8 May 2023
Line 416:		Line 416:
	=== Github ===		=== Github ===
	==== Use SSH for Github Authentication ====		==== Use SSH for Github Authentication ====
	~~I prefer using~~ SSH for Github instead of HTTPS, ~~just because I don't have to think about credentials~~. ~~This is a personal preference however and there~~ is much debate over which is 'better' or more secure. If you want to try this, you can start [https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent '''here'''].		You can use SSH for Github instead of HTTPS. It's convenient because it can make authentication easier (no prompts for usernames/passwords, etc.). There is much debate over which is 'better' or more secure. If you want to try this, you can start [https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent '''here'''].

	==== Delete branches after merging!!! ====		==== Delete branches after merging!!! ====

Frost Salamander: /* Bugfix Workflow */

2023-04-15T14:11:26Z

Bugfix Workflow

← Older revision		Revision as of 14:11, 15 April 2023
Line 377:		Line 377:
	'''It is strongly recommended to have [[Git_and_Github_for_Mappers#Protect_the_default_branch\|branch protection]] turned on for this workflow.''' This will prevent any accidental changes.		'''It is strongly recommended to have [[Git_and_Github_for_Mappers#Protect_the_default_branch\|branch protection]] turned on for this workflow.''' This will prevent any accidental changes.

	It looks like a lot of steps, but like other parts of this tutorial it becomes second nature and only takes a few seconds to perform.		Essentially what we're doing here is performing each fix in a separate pull request. The reason for this is to take advantage of the automated release notes, which expect each individual fix or change to be in its own PR. It looks like a lot of steps, but like other parts of this tutorial it becomes second nature and only takes a few seconds to perform.

	# Once a bug or change is identified, [https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue create an issue] in your repository. For example, let's say we now have issue #8.		# Once a bug or change is identified, [https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue create an issue] in your repository. For example, let's say we now have issue #8.

Frost Salamander: /* Bugfix Workflow */

2023-04-11T09:59:26Z

Bugfix Workflow

← Older revision		Revision as of 09:59, 11 April 2023
Line 394:		Line 394:
	# '''At this point, if you have TDM open, close it.''' If you don't, when you change branches in the next step Git will think the local map file has been modified. I think this is because TDM locks the .map file, so when you sync from Github it was not able to update it and shows it as changed from the version you just pulled from Github.		# '''At this point, if you have TDM open, close it.''' If you don't, when you change branches in the next step Git will think the local map file has been modified. I think this is because TDM locks the .map file, so when you sync from Github it was not able to update it and shows it as changed from the version you just pulled from Github.
	# In your local git repo on your PC, change back to the 'main' branch and sync changes (or 'git pull' if using command line).		# In your local git repo on your PC, change back to the 'main' branch and sync changes (or 'git pull' if using command line).
	# If you didn't close TDM ~~or for some reason you get a merge conflict at this point~~, just revert any local changes and pull from Github. Your changes have been stored safely in Github and branch protection will prevent anything from getting lost/overwritten.		# If you didn't close TDM and git is showing the .map file has changes, just revert any local changes and pull from Github. Your changes have been stored safely in Github and branch protection will prevent anything from getting lost/overwritten.

	==== Subsequent Beta Releases ====		==== Subsequent Beta Releases ====

Frost Salamander: /* Bugfix Workflow */

2023-04-11T09:58:15Z

Bugfix Workflow

← Older revision		Revision as of 09:58, 11 April 2023
Line 392:		Line 392:
	# Click 'confirm merge'		# Click 'confirm merge'
	# Delete the branch		# Delete the branch
	# '''At this point, if you have TDM open, close it.''' If you don't, when you change branches in the next step Git will think the local map file has been modified (not ~~sure why this happens)~~.		# '''At this point, if you have TDM open, close it.''' If you don't, when you change branches in the next step Git will think the local map file has been modified. I think this is because TDM locks the .map file, so when you sync from Github it was not able to update it and shows it as changed from the version you just pulled from Github.
	# In your local git repo on your PC, change back to the 'main' branch and sync changes (or 'git pull' if using command line).		# In your local git repo on your PC, change back to the 'main' branch and sync changes (or 'git pull' if using command line).
	# If you didn't close TDM or for some reason you get a merge conflict at this point, just revert any local changes and pull from Github. Your changes have been stored safely in Github and branch protection will prevent anything from getting lost/overwritten.		# If you didn't close TDM or for some reason you get a merge conflict at this point, just revert any local changes and pull from Github. Your changes have been stored safely in Github and branch protection will prevent anything from getting lost/overwritten.

Frost Salamander: /* Bugfix Workflow */

2023-04-11T09:53:51Z

Bugfix Workflow

← Older revision		Revision as of 09:53, 11 April 2023
Line 372:		Line 372:

	==== Bugfix Workflow ====		==== Bugfix Workflow ====
	This is my own personal workflow. It suits me, and helps keep me organised and makes it easy to share progress with beta testers.		Now that testers have got ahold of your beta FM, the bug reports start rolling in.
			This is my own personal workflow for handling these. It suits me, and helps keep me organised and makes it easy to share progress with beta testers.

	'''It is strongly recommended to have [[Git_and_Github_for_Mappers#Protect_the_default_branch\|branch protection]] turned on for this workflow.''' This will prevent any accidental changes.		'''It is strongly recommended to have [[Git_and_Github_for_Mappers#Protect_the_default_branch\|branch protection]] turned on for this workflow.''' This will prevent any accidental changes.

Frost Salamander: /* Initial Beta Release */

2023-04-11T09:52:24Z

Initial Beta Release

← Older revision		Revision as of 09:52, 11 April 2023
Line 363:		Line 363:
	==== Initial Beta Release ====		==== Initial Beta Release ====
	You're ready for beta and want to make the .pk4 available for your beta testers. Do the following:		You're ready for beta and want to make the .pk4 available for your beta testers. Do the following:
	# ~~(optional)~~ Ensure all your branches are cleaned up and ~~you are only left with the~~ main branch		# Ensure all your branches are cleaned up and your main branch is up to date
	# Do a clean DMAP of your FM (i.e. delete all .proc, .cm, .aas files, etc. first)		# Do a clean DMAP of your FM (i.e. delete all .proc, .cm, .aas files, etc. first)
	# Package up the .pk4. I use a Powershell script, but you can do whatever suits you.		# Package up the .pk4. I use a Powershell script, but you can do whatever suits you.

Frost Salamander: /* Bugfix Workflow */

2023-04-09T12:17:44Z

Bugfix Workflow

← Older revision		Revision as of 12:17, 9 April 2023
Line 385:		Line 385:
	# Go to your Github repo in the browser and view the 'code' section. Github should notify you that a new branch has been pushed and ask you if you want to raise a pull request. Do so.		# Go to your Github repo in the browser and view the 'code' section. Github should notify you that a new branch has been pushed and ask you if you want to raise a pull request. Do so.
	# In the pull request (PR for short), make sure the title is something descriptive as it will show up in the release notes later. For example 'Fix z-fighting on castle wall'.		# In the pull request (PR for short), make sure the title is something descriptive as it will show up in the release notes later. For example 'Fix z-fighting on castle wall'.
	# In the description, reference the issue you are fixing. This will associate the PR with the issue. For example, type 'fixes #8'.		# In the description, reference the issue you are fixing. This will associate the PR with the issue. For example, type 'fixes #8'. If you can't remember the issue number you need, just glance up at the branch name you are merging in the PR. This is why we name the branch after the issue :-)
	# Add a label to the pull request (e.g. 'bug'). This will categorise the fix in the automatically generated release notes.		# Add a label to the pull request (e.g. 'bug'). This will categorise the fix in the automatically generated release notes.
	# Click 'create pull request' and then 'merge pull request'.		# Click 'create pull request' and then 'merge pull request'.