<cat>Hammer.Advanced</cat> Please note that right now this article assumes a lot of knowledge, and I hope to fix that with feedback and other community contributions over time. Right now this is a decent starting point while we figure out and refine our workflows between one another. This article will use terminal based git commands, because these can be easily translated back into other git GUI/software of your choosing. ## Git and Hammer Level Design Workflow ⤶ Git is a tool that helps manage code and changes made to it by multiple people. It's useful for teams working on the same project because it allows them to work on different parts of the code without interfering with each other. ⤶ In our Hammer level design workflow, the main development branch will contain the main .vmap file, which is the main level file. Each team member will create a separate branch off of the main development branch, which they will use to work on their assigned prefab during the blockout phase. ⤶ ### The Blockout Phase⤶ ⤶ After the initial rough blockout phase, each section or objects within a section that will be distributed for work by other team members will need to be encapsulated into a prefab. **This is the last time you will touch the main level's .vmap on this branch until it's time to review all changes together.**⤶ If you don't already have Git LFS installed for your repo, you're going to need it. Read more about it [here](https://git-lfs.com/). ⤶ Git is a tool that helps track changes to a project, typically code, and provides a powerful set of tools for managing different versions of the project as well resolving conflicts that may arise when multiple developers are working on the same project. It's also very useful for working on different parts of the same projects without interfering with each other. ⤶ In our Hammer level design workflow, the development branch will contain the main .vmap file, which is the main level file. Each team member will create a separate branch off of the development branch, which they will use to work on their assigned prefab during the block-out phase.⤶ ⤶ ### The Block-out Phase⤶ ⤶ After the initial block-out phase, each section or objects within a section that will be distributed for work by other team members will need to be made into a prefab. **This is the last time you will touch the main level's .vmap on this branch until it's time to review all changes together.**⤶ #### Prefab Assignment Team members will be assigned specific areas of a map to work on so that they have a clear focus and responsibility. ⤶ One way to manage these assignments in a git workflow is to encapsulate each object or area of the map into a prefab. These prefabs can then be assigned to individual team members for them to work on. ⤶ When a team member is assigned a prefab, they can create a new git branch off of the development branch and name it after themselves for organization purposes. Once they have created their own branch, they can then create a separate branch for their assigned prefab. ⤶ While working on their assigned prefab, **team members should only make changes to the prefab** and commit those changes to their branch using the "`git add`" and "`git commit`" commands. They can then push their branch to the remote repository using the "`git push`" command. ⤶ Once the work on the prefab is complete, the team member can create a pull request to merge their changes back into the main development branch. This pull request can then be reviewed by other team members, who can provide feedback or make suggestions for changes. Prefab changes are reflected almost instantly in Hammer, assuming that it already exists within the main level file.⤶ Team members will be assigned specific area of the map or object to work on so that they have a clear responsibility. One way to manage these assignments in a git workflow is to make each object or area of the map into a prefab. These prefabs can then be assigned to individual team members for them to work on. ⤶ When a team member is assigned a prefab, they can create a new git branch off of the development branch and name it after themselves for organization purposes. Once they have created their own branch, create a another branch for their assigned prefab. ⤶ **team members should only make changes to their prefab**, no one else's. This can cause conflicts down the line if someone else's prefab is changed and you're merging your changes into the development branch. ⤶ Once the work on the prefab is complete, the team member should create a pull request to merge their changes back into the main development branch. This pull request can then be reviewed by other team members, who can provide feedback or make suggestions for changes. Prefab changes are reflected almost instantly in Hammer, assuming that it already exists within the main level file. ### Branch Naming This isn't required but it could be helpful if you're new to git or source control. Each team member should branch off the development branch using their name initially, for example, **Aleph** branches off the development branch, naming their branch `Aleph`. The team member should then create a separate branch for their assigned work, such as a prefab, and name it accordingly. For example, Aleph has been assigned to work on a prefab called "`house01_1`", so they can create a new branch off of their own branch, naming it "`house01_1`". #### .gitignore File After creating and checking out their branches, each team member should create a .gitignore file and add the following: ``` *.vpk *.los *.dmx mainMapFile.vmat ``` ### Git Commands Setting up the development branch: ``` git checkout -b dev-0.1 main ``` Team Member Branches: ``` git checkout -b myname dev-0.1 ``` Committing Changes: ``` git add . git commit -m "Updated myprefabname" ``` Pushing committed changes to remote: ``` git push origin myfeaturename ``` Merging Changes: ``` git checkout myname git merge myfeaturename ``` Pull Requests: ``` Create a pull request on Github. Add a title and comment. Press the Create pull request button. Wait for team members to review ``` #### Pushing huge changes Note: If your project is huge, you're going to have to make your changes in pieces, your remote pushes can timeout if you're pushing something over 5 gigs. Use your .gitignore to break your project up into smaller pieces. Remove file paths & extensions from .gitignore as you're ready to push them. Keep it small, git hates large files, and it hates files that aren't code so it's actively working against you.