-
Notifications
You must be signed in to change notification settings - Fork 1
Git Branching
When creating a new feature for the project it is best practice to create a new branch that contains all of the changes you are making related to that feature. This is to make it easier to track what changes are being made to the project and also to limit the number of merge conflicts that arise when two or more people make changes to the same base file.
Git branches are places where code breaks away from the main branch to be edited before later being merged into the codebase. In order to help visualize the process I will use making car repairs as an example.
Following a git cheat sheet, you will more than likely see that there are two pretty common ways to create a new branch. The first is the command git branch <branch name> this will create a new branch but it will NOT automatically switch you to the new branch. In order to switch to your newly created branch you will also need to use the command git checkout <branch name>.
Alternatively, this can be done in one command instead by using git checkout -b <branch name> this will both create a new branch and switch you to use that branch as well all at once. It's important to note that branch names cannot contain whitespace. Words must be separated by underscores or hyphens.
To follow our car example, creating a new branch is like assigning yourself to change the oil. Once assigned to that task, ideally, you would change the oil without making many other changes to the car. In some instances, however, you will need to remove parts or replace others in order to change the oil and this could possibly interrupt another mechanic's assigned task. This is what is known as a Merge Conflict and we will get to that later.
After you have made changes to a file you will notice the color will change. New files will turn green and have the letter U next to them while modified files will turn an orangish yellow and have an M next to them. These are your pending changes from the baseline that you cloned. In order to prepare these changes to be sent to the repo you will need to stage them. This is done by using the git add command. git add can be used either by providing the specific name of the file you want to stage i.e. git add index.js OR you can stage every change at once using git add . that is a period which basically just means "stage everything".
Once changes are staged they can be removed from the staging area at any time. This is done with the git restore command and it works the same as add wherein you can provide the specific filename or use a period to choose everything.
When you are happy with the files you have in the staging you need to commit them. This is done using the git commit command. The important thing with git commit is that you are almost certainly required to provide a commit message as well. This is achieved by using git commit -m <commit message>.
GOOD COMMIT MESSAGES ARE DESCRIPTIVE
- Be sure to make it obvious what you changed at a glance, the reviewer can always see what actual changes you made but it helps them to know exactly what they are looking for. Good: Fixed Typos: Missing @ symbols in e-mails on the contact us page Bad: Big Changes!
After you have made a fantastically descriptive commit message to go along with your completely bugless code, you will need to push the changes to the repo. This is done via the aptly named git push command. The actual syntax for the command will be git push origin <your branch name> origin, which refers to the repo you cloned/ forked and should already be set. If it is not it is pretty easy to set/ change. If you have forgotten what you named your branch you can easily see it using the git branch command by itself with no arguments. It will even highlight the current branch you are on in green and with an asterisk!
Finally, in the home stretch, I realize the car analogy broke down but I started to realize it made more sense to just keep explaining how it works. Once you have pushed your changes to the repo you need to head to the repo page. There you will see a little banner above the code file directory. It will ask you to make a Pull Request for your most recent commit.
The reason it is called a Pull Request is that you are requesting for your branch of changes to be pulled back into the main branch and become an official part of it. In the pull request form, you can add additional details and descriptions that you may have not covered in your short commit message. Once that's done you have done it! You took a new branch from creation to finally having a chance to get merged into the main codebase.
Inside a pull request, there is an area for feedback from the reviewers. This is where they can let you know if they want you to make any additional changes.