Work has started.
Local changes were made.
Changes history needs to be saved and pushed to a remote repository.
Congrats. You’re versioning now.
This is where you make the switch between what’s saved and what you just did.
This is also where you usually break things.
Git add, commit and push. Easy, right?
If you’re thinking “!?!”, calm down. Read this post. Then come back.
Ok, feel better now? Good. So you did some work, saved some stuff locally and pushed it to Bitbucket (or to what ever remote repo you’re using) like a boss. Good.
Then you broke it. Well, I know I did. And unless you revert back to a previous version you don’t have anything working properly anymore.
The solution to avoid that is branching.
Glad you asked. Branching means pointing your project repository to a side project of sorts called a branch. You can work in there, not impacting the project (ie. not changing the main branch called master) until you’re ready to.
How do I use a branch?
First you create it and “select” it. Git calls that checkout. In SourceTree, click Branch and give it a name. Here are the Git commands happening:
git branch BranchName git checkout BranchName
How should I name branches?
How do I save my branch on my remote repository?
You should know the git lingo for this at this point. It’s push (not save). Just like pushing the master branch but with the other branch checked out.
git push origin BranchName
How do I put my changes into the main branch?
The main branch is called master. So start calling it that. To have your changes in there, you need to merge your branch into master.
git checkout master git merge
Go nuts. You can break everything in a branch and not care. Master is safe. Just try some things, prototypes some ideas. And when you’re ready. git merge baby.