Git is a distributed revision control system which is commonly used for managing source code in software projects. It was initially created on 7th April 2005 by Linus Torvalds to manage the source of the Linux kernel and has become the defacto standard for source code management.
Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.
Git is a powerful tool that allows us to be a productive development team, some of the benefits are:
Allows us all to be working on multiple different features simultaneously, even on the same file.
Conflict resolution handling built in.
The standard in web development version control
I will be running with you some concepts of Git, these are:
Git is made up of branches, all repos will have a Master branch. This is considered the root of the repo and in a software development context it is considered the source of truth for the production product.
All features for the project are branched off from Master, the benefit of this is that every branch has a stable base to work from. An example of doing this is `git checkout –b new-feature master` which will create a new branch call new-feature from Master.
git checkout –b new-feature master / git checkout –b new-feature which is short hand for git branch new-feature git checkout new-feature.
Committing is the process of adding your changes to repo to version control, a change can be adding or removing files or adding and removing lines of code from a file. Git treats them both as a change, changes must be added before they can be committed.
Let’s say you added a new line to react-component.jsx, you would need to do git add /location/from/route/react-component.jsx and then do git commit –m “add new line to react-component". It is considered best practice to commit often and push regularly.
Merging is the process of taking your changes from one branch merging them into another, for example merging new-feature in to training. This is a method of combining code from multiple streams into a single stream. This is how Pull Requests on GitHub work as well.
Remember that things can change when you started you branch and so when you merge back in, in the future there may be a conflict. Conflicts arise when a file has changed between your changes and changes on the target branch.
If you were to merge into develop your local new-feature branch into develop you would need to do the following:
git checkout develop
git merge new-feature
Rebasing is an advanced feature of Git and it allows you to merge your code into another branch. This works in a different way to a merge command and gives you more power during the rebase, for example doing a rebase will allow you to squash all your commits into a single commit keeping the git history clean.
The diagram below shoes the before and after:
Do's and Dont's
When starting new pieces of work branch of Master
Commit often and push regularly
Commit messages should have useful information so another developer can take them on
Squashing commits into a single commit on merge helps keep the git history clean and relevant and if possible add the ticket information to the merge commit
Never mess with history unless you are fully comfortable with Git
Here are some handy resources that might be of use to learn Git in your own time.
A guide on good branching: https://nvie.com/posts/a-successful-git-branching-model/
Remember there are multiple ways to use the Git service, the GitHub desktop app, VSCode and the CLI. They all run from the same background service so you aren't stuck with one tool, research and see what works best for you.