Creating Branches and Pushing files to GitHub.
Unity Log, Stardate: -300168.833999239 (October 31, 2022, Time: 9:00:51 AM MDT)
Objective: Instruct the reader on Pushing Commits to GitHub and creating Branches.
Getting your files committed to github is great, but the actual files are not really there until you actually upload them to GitHub. This is where the git push command comes into use. This allows other users to see the changes you’ve made. If the owner of the repository approves the changes, then they can be merged with the Main Branch.
To get your changes pushed onto a new branch on Github. You will want to run git push <origin> <branchname>. GitHub will automagically create the branch for you on the remote repository. GitHub will ask if you want to create a new repo from scratch or if you want to add your repo that you have created locally. Since we had already created our new repo locally, we want to push that onto GitHub or push an existing repository from the command line section.
Branches are what allow you to move back and forth between varied versions or “states” of a project. Git docs describe a branch as, “…a simple, lightweight movable pointer to one of these commits. If you want to add a new line of code to your project without affecting the main part of the project, the branch allows for the manipulation of the file, while leaving the overall project untouched. Once you have made your modifications and tested them, then you can merge your changes from your branch to the primary or “main” branch. “
When created, a new branch is tracked by Git by keeping track of which commit your branch ‘branched’ off of, so it knows the history of all the files in the project.
As an example, we are on the primary “main” branch and you want to create a new branch to develop your project. run git ‘checkout’ or switch -b <my branch name>. This command automatically creates a new branch and then “switches” to it, meaning git will move you to that branch, from the “main” branch. Type the command “git branch” to confirm that the new git branch was created. The branch with the <*> asterisk next to it indicates the branch you are in at that present moment.
Unity Log, Supplemental, Stardate: — 299851.6738013698 (February 24, 2023, Time: 3:20:15 PM MDT)
Our previous portion of the article we discussed pushing commits and the branching out in Git. Let’s cover the use of branches and the importance of this workflow to insure quality version control.
When working on your project with other people, this is when version control becomes magical. To see how all the various facets of a project can seamlessly work together, developed by different people all working within the projects branches and merging them into a final product. That is the magic wand of GH.
There are three rules to always follow when working in GH this will always help you when working on projects with others.
Rule #1: Create a Git Repository for every NEW project
Rule #2: Create a branch for every NEW feature
Rule #3: Use PULL Requests to merge code to your Main Repository
I would suggest that even when you are working alone or on small or simple projects to follow these rules every time you write code to help you learn Git and GitHub thus making the process second nature.
Why these rules, you ask? Let me spell it out.
Rule #1 Create a Git Repository for every NEW Project: This rule is fairly self evident. By following it every time you start something new, you make it a habit. So everytime you work on your portfolio, or learn a new project you should create a repository and push it to GitHub.
Having a dedicated repository is the first step in being able to use version control for every line of code you write. This is how you will perform your work in the real world when you start working on real-world projects.
Rule #2: Create a branch for every NEW feature: You are working on your game development assignment and you are adding a feature to enhance your game. Create a branch for this new feature and give it a meaningful name (i.e. glitter cannon), and commit all the code you write for that specific feature to this specific branch.
By teaching yourself to work with branches you and anyone else you work with will be able to work on different features in parallel while keeping the specific code for each feature isolated from the rest. This makes it harder for unstable code to become merged with your main repository base.
Even if you are a team of one, getting used to the idea of feature branches will make your github processes work seamlessly when in an actual team environment.
Rule #3: Use PULL Requests to merge code to your Main Repository: Every Repository by default starts with a MAIN branch. One should never push changes directly to your Main Branch. Feature Branches should be used instead. You then open a PULL request to merge your features with the Main Branch code.
In real world situations, someone looks at the Pull Request and does a code review before approving it. Git Hub can also run automated tests to your code to help you identify any potential issues with your code. You will be notified if there is a potential merge conflict between your code and the code in your Main Branch.
Once your code has been reviewed, tested and approved, the reviewer will approve your Pull Request to be merged with the Main Branch code.
This is a best practice, basic workflow used by the majority of developer projects. Having a working understanding of these three rules, you will find it easier to contribute to a project and have your work accepted without any problems.
