More Git Detials

I used two resources today
- Git & GitHub Tutorial for Beginners #11 - Collaborating on GitHub
- GIT: Branching and Merging from Udemy
  - This is a $10 class right now.
  - It was worth it for me to try to get up to speed.
  - But I would not rate it very highly.
    - He spends too much time teaching you how to do useless stuff
    - He spends a lot of time goofing around.
  - I have the last chapter to watch on conflicts.
- My Git book arived today
For single person projects
- The workflow from last time will be great.
- Create your project.
- Add it to a private repo as in the notes.
- Invite me to the private repo.
- Or create a public repo and send me the url.
Workflow overview
- So I have a public repo for the Twin Stick Shooter Tutorial.
- I will add a a cone to my level.
- Then press save.
- In GitHub Desktop, click in the file area
- Then I can either update in unreal by clicking on
  - Source Control -> commit to source control
    - Which brings up a dialog,
    - I need to add a comment
    - Then back on GitHub Desktop I now need to push this out.
  - Or just push the update in Github Desktop
    - Fill out a comment
    - And select Commit to Master.
  - Either way looks good.
- I would push when I finsh a major task.
I have been playing with GIT and I think the only place you will get into conflict is if you work on the same thing.
- We will see more of this in the demo, but problem decomposition is the main problem.
- I don't know the underlying structure of the Ureal project very well
- But I think if you break things up well, you will be ok.
- So it is very important to provide clear delination of work for the group.
  - Person 1, you will build a blueprint that ....
  - Person 2, you will build a ui that ...
  - Person 3, you will build an AI for the ...
- Be careful when you are editing a common asset like the player controler
  - Make sure that no one else is working on that asset.
  - Make sure that all forks are merged.
  - Work on the asset
  - Merge back
  - Update the master
  - Update all branches.
  - Then each of you TEST YOUR PART to see if things have broken.
What would I do for group projects.
- The key to avoiding confilcts is to not change the same places in the same file.
- More later but
- I would build a folder per person
  - All the blueprints they create will be in this folder.
  - All the everything they create will be in this folder.
- I would build a level per person
  - All of their work is done on that level.
- I would create one branch per person.
  - They are responsible for uploading their work in small chunks.
  - They are responsible for creating push requests regularly.
- Only the project manager is responsible for merging the product.
- You will probably need a public project
  - As I read it, you can only have three members of an group in a private project for free.
Let's work through a demo at a lower level.
- I'm going to create a simple C++ project.
  - Hellow World really.
- I'm going to work on it from both my Linux Machine and my windows macine.
- Create a new folder Hello World Project
  - Create a shell hello.C in the directory
  - Using GitHub Desktop create a new repo.
    - As before, Add local repository
    - Select the path.
    - Create a new repository.
    - Publish the repository
- Over on github a new repo has appeared.
- Now I want to clone this repo on my linux box.
  - make a new directory
  - git init
  - git clone https://github.com/danbennett360/Hello-World-Project
- On the linux side I am going to create a makefile.
- I now need to add it to my project
  - get add Makefile
  - This stages the Makefile to be uploaded on the next check in
  - I can see this by running git status
  - If I run make it will build main, but I don't want to commit that.
  - But run git status anyway
    - Notice titells me that hello will not be included.
    - That is ok, no need to store the executable.
    - By the way, Unreal adds a .gitignore file that tells it to ignore many items we don't want to upload.
  - I now need to commitit it to the project
  - git commit -m "adding a makefile"
  - And push the change
  - git push origin master
- If I referesh on Github I see that Makefile has been added
- I shoudl click on Fetch origin on GitHub Desktop
  - And it will tell me that the files have changed
  - So I should do a new pull request.
  - And looking in the directory, Makefile has appeared
Lets modify the file on both sides.
- On the linux side I will add a comment
- On the windows side, I will add command line arguements
- On the windows side, I can push with GitHub Desktop
- When I try to push on linux however
- - Arg so we will not fully go into this now but
    - I need to unstage this file
    - git reset HEAD hello.C
    - And get the last version
    - git checkout hello.C
  - Now I can update it.
  - Not soo good.
Branches are the way to solve this.
- Branches are not forks.
  - Forks are new versions of the project.
  - A branch is a temporary work space in the project.
- I'm going to create two branches on github.
  - arguments
  - This is to build command line arguments.
  - I will work on this on the windows side
  - and documentation
  - This is to add comments, I will work on this on linux.
- On Windows,
  - I need ot fetch the origin
  - Then the new branches show up.
  - I don't want to do a pull request right now.
  - But I will edit the file.
  - and commit the changes.
- On the linux side
  - git pull
  - Will show me that there are two new branches.
  - I will switch to the document branch with
  - git checkout documentation
  - I will edit the file, add, committ and push
- Back on github I see that there are two new reciently pushed branches
  - Each submitter needs to create a pull request
    - This is a message to the project manager that they want to put their code back into the main line.
    - Just click the button and fill out the form.
  - The PM notices the pull requests
    - Selects one and merges it.
    - And does the same with the second.
- Back on linux, I pull everything down to the master
  - git checkout master
  - git pull origin master
- Merge the master back to my local document branch and push it back up
  - git checkout documentation
  - git merge master
  - git commit -m "After Major Merge"
  - All is well.
- On windows
  - Set the branch to the master and pull origin
  - Change the branch back to the arguments branch
  - And select Update from master
  - This will do a push back to gethub.
- Group workflow
  - Starting
    - Project leader make the project.
      - Upload the starting system for your game.
        
        In ths make a level for each team member.
      - Create a new branch for each team member.
    - Team members
      - Clone the repo after it has been created.
        
        In the GitHub Desktop
        From the repo menu select clone
        
        It should show up if your project leader has shared it.
        If not, use the url
        
        Make sure you switch to your branch.
      - Work and commit as below.
- As the project progresses
  - Team Members
    - Pull your branch
    - Work, work well, work hard, work fast.
    - Commit your changes
    - Upload and create a push request.
    - After the merge
      - Pull down the new master
      - Merge it with your branch
      - Push up the new branck
    - Rinse, repeat
  - Project Leader
    - Regularly perfrm merges to keep the code base up to date
My takeaway
- I would create a branch for each team member.
- I would merge branches frequently.
- Everyone work in their own level
- Let people know when you are about to change something central.