Learning Git is no joke!
If you are a developer, and you work alone, or haven't gotten a chance to work an organized team, this article is for you!
When I joined This Dot Labs as a junior software developer, I encountered a ton of issues with Git in my first weeks.
In this quick blog, I'll share what I learned from my team with the hope that it will make your life easier when you join your own team, and start using Git collaboraboratively.
1. Pull Request (PR)
When you’re working as a developer on a big collaborative project, things get complicated. You're not only worried about making mistakes yourself, but you're hoping nobody else's bugs get merged into the shared code either. So how can a team of developers organize their work flow to better work together?
The generally accepted best practice is not pushing to the main branch at all. Instead, separate the work into small pieces. Each piece is a new feature in the project, and developers code each feature on a separate branch. Then, they open a pull request, and that means they want to merge their changes with the main branch!
Next, your pull request will be reviewed by team leads, tested, and hopefully approved.
If you receive that approval, congratulations! You can merge your branch into main branch now. 🥳
2. Husky
This is a tool that we use to run scripts and tests before we commit, or push changes to get high-quality commits! For more information, visit https://typicode.github.io/husky.
3. Rebase
This was the most difficult topic for me to grasp in the first two weeks, but I finally got it! I will simplify it with graphs to make it easier to understand.
Imagine we are working on a project, and we have three commits: m1, m2, and m3:
If you had to write code for a new feature in the project, you would have to create a new branch, like this:
Now, the feature branch is based on the last commit of the main branch, which is m3.
After ceating this branch, you might add some commits, which are represented by f1, f2, and f3:
But while you're coding, one of your teammates could add some commits to the main branch, and now the main branch looks like this:
If this happens, your branch is behind the main, so you need to rebase it to the latest version of the main to see these changes with the next command.
git rebase main
And this is how your feature branch looks now:
Now, as you can see, the rebase process pushes your commits forward, so your branch is based on m5 instead of m3, and you have the latest version of the changes.
And if you open the git log, the commits in your feature branch will look like this:
4. Git fetch vs pull
This also confused me at the beginning, but let’s simplify it! If you haven't worked on a team yet, you've probably only used Git push and pull commands because you’re the only developer on the project!
git fetch is the command that tells your local git to retrieve the latest meta-data info from the original (Though it doesn’t do any file transferring. It’s sort of "checking" to see if there are any changes available).
git pull on the other hand does that AND brings (copies) those changes from the remote repository.
So to summarize this, git pull does a git fetch, followed by a git merge.
5. Git strategy (Rebase vs Merge)
There are a lot of ways to use Git, and I see a different method in each project I work on. But, these are the two patterns I saw most frequently.
Merge Strategy
Imagine you’re working on a website, and the client wants you to add a new "About" page.
Using this strategy, you’ll make a new branch for the new page. Then, you will divide this page into smaller pieces/components, and make a new branch from the main feature branch (the About page branch) for each one. After this, you will merge these smaller branches into the feature branch, and when the "About" branch components are ready, you can merge the About branch into the main branch.
Pros of this strategy:
It’s safe, and protects everyone’s work!
Cons of this strategy:
As you can see from the image above, the branches can get complicated!
Rebase Strategy
To avoid some complexities in the Merge strategy, especially in very large projects that may contain thousands of branches, you can rebase your commits.
A rebase takes your commits, and reapplies them with a new position. You are essentially moving your starting point.
After rebasing a commit, it will look like the code from a single straightforward line, like this:
Pros of this strategy:
The main branch will look like the code from in a single straightforward line!
Cons of this strategy:
Rebasing does have its risks, and can result in you losing your work.
Final thoughs: Every Git strategy has pros and cons, and so much of the strategizing process will depend on team preference. I bring up these two options as they are the most common you will encounter when you begin working on collaborative projects with Git.
About the author
