You know how to setup a project with Git and connect it to GitHub. You understand how Git's staging step works and commits don't scare you anymore (do they?).
It's time to learn how to do things the way big children do them 🤠.
Create a feature branch 🌱
When you start working on a project linked to a remote repository you are provided with a default branch called master (recently renamed main).
You can touch by hand by typing in the terminal (be careful to have navigated to the exact folder):
git branch.
At the moment there is only one branch and consequently it is selected.
Now you want to implement a new feature in your project.
Rather than going to dirty the master branch (which is the one that carries the safe, tested code, possibly addressed to production), you decide to work on a specific branch for the new feature.
Create a new branch with the command:
git checkout -b [feature_branch_name].
Here, for simplicity's sake, you've created a branch for inserting an HTML file. Obviously, it's overkill in this case, but I'm sure you will go further and understand the potential of what you are about to learn.
As soon as you create the new branch you are moved to it. Use again git branch to find out:
Do you want to jump from one branch to another? Just
git checkout [feature_branch_name]and optionally check withgit branch.
At this stage, there is absolutely no difference between the master content and the new branch one. The reason behind the branching is that any changes you commit will be constrained into that and only that specific branch. The master branch itself is not affected in any way (at least until you decide otherwise).
You may be wondering "why make life so complicated 😵?".
Well, you're actually simplifying it: you can finally work with peace of mind on features that could break code or leave them pending while you complete something else.
Furthermore - and that's sufficient - the concept of branching is crucial to team working.
So proceeding with the example, you make sense of existing to the feature-branch by creating an HTML file. Add it, commit it, push it.
Since this is the first time you are pushing this branch, you need to set the upstream with
git push -u origin [feature_branch_name].
Obviously, the branch function is fulfilled when the feature is merged into the master code. However, I would like to familiarize you with checkout before proceeding. Try to switch to the master branch with git checkout master.
Pop! Look at your folder structure: the HTML file is gone. Go back into the feature-branch and... there it is.
Merge branches 👯
You could just checkout to the master branch and use the command git merge [feature_branch_name] and git would merge the two branches into a single shiny one.
But there is a more professional way of closing the circle. And this is called doing a PR (pull request). As the name implies, it is a request to pull code into another branch.
Feature_branch ---> Master_branch
From the moment you pushed the feature branch, this appeared in the repository on GitHub:
If you are an attentive and curious child you will have noticed that when you did the push you were given a url address
Clicking here is basically the same as clicking the green button.
You create the pull request and you are sent to this page. It is well specified that the feature branch is injected into the master branch.
Below you are asked to give a title to the pull request (usually by specifying the GitHub issue that generated it). In the body it is a good idea to give detailed explanations, perhaps with a nice list, explaining the reasons, obstacles and solutions adopted.
Finally, you hit that inviting green button and you feel like a slightly better programmer.
On the new screen you and others can:
- add comments to
- ask for information
- request additions or changes
- share knowledge
- trace the history of the commits
- in fact, you can safely continue to push changes on the requested branch pull
- examine the files and add specific comments to the line of code
- hover on the line, you will see a blue + button
Since it is your pull request you have permission to resolve conversations.
When it all adds up, you can finally proceed with the merge.
CLICK!
A pull request is born, throws a tantrum, eventually matures, and finally, alas, dies. Don't cry, it's the cycle of life...
Anyway you can always bring it back to life 🧟
Seriously, let's take a look at the remote repository.
It is actually the result of the merge between the two branches. Yet locally despite being in the master branch you do not see any index.html file, why? You need to pull locally the updated remote repository with the command
git pull origin master
And here everything is as it should be.
Finally, delete 🪓 the branch with the command
git branch -d [feature_branch_name]
This is the basis and it's not always that simple. Often you will run into merge conflicts ⚔. If you like, give it a look.
Otherwise, continue with the fork [VERY_VERY_SOON].
🐤 twitter: https://twitter.com/did0f
Top comments (0)