Deploying your project via a remote repository lets you flexibly manage every bit of it. Bug fixes, feature updates, file deletion, teamwork, open-source contributions, code deployment, and more are now at your fingertips with a strong knowledge of Git.
So, you’ve been using Git but want to know more? Here are some more advanced Git tips that’ll make your project version control a breeze.
Git Branch
A Git branch prevents you from pushing directly to the master branch. It’s helpful if you manage a project with a team of developers. You can create as many Git branches as you want and then merge them to the master branch later.
Create a Git Branch
To create a Git branch, use:
git branch branch_nameSwitch to a Git Branch
Use checkout to switch to a Git branch:
git checkout branch_nameAfter switching to a branch, you can stage your changes using git add –all. Then commit them using the git commit -m “commit name” command.
Compare a Branch With Master
Use the git diff command:
git diff master..branch_nameTo compare specific files:
git diff master..testb -- main.htmlComparing two branches is similar to how you compare a branch with the master:
git diff branch1..branch2To see the differences in a specific file between two branches:
git diff branch1..branch2 -- main.htmlPush Changes to a Remote Branch
You might want another developer to look at the changes you’ve made to a file in your local branch before pushing them live. A good practice is to shove your local Git branch to a remote replica so they can have a look.
Let’s assume that you’ve previously created a local branch named changes. You can switch to that local branch, adjust all the files you want, then stage and commit them to that branch.
You can then push those changes to the remote version of the branch:
git push origin changesMerge Remote Branch With Master Using Pull Request
So another programmer has audited the changes in the remote branch (changes). But you want to merge it with the master branch and push it live.
Remember that your remote branch inherits the name of your local Git branch (changes). Here’s how to merge the changes:
Switch to the master branch:
git checkout masterPull the origin or HEAD of the branch (changes) to merge it with the master branch:
git pull origin changesPush this merge live to the master branch:
git push origin masterUse Git Merge Instead
To merge a branch with the master using the merge command:
Migrate to the master branch:
git checkout masterMerge it with the branch (changes):
git merge changesThen push the merge live to the master branch:
git push origin masterEnsure that you replace changes with the name of your branch.
Once a merge is successful, you can then delete the branch locally and remotely if you don’t need it anymore:
Git Rebase
If you have multiple branches with outdated commits, you can rebase or refocus the head/refs of those branches to inherit the head/refs of an updated one.
Rebasing, therefore, comes in handy when you need to update some branches with the base of a current one.
Rebasing shouldn’t be a frequent action, though, especially if you’re working with a team as it can disrupt the entire workflow. But if you work alone and you’re familiar with your workflow and branches, rebasing shouldn’t wreak havoc if you know where and how to use it.
For instance, assume that you have two branches; branch1 and branch2. Now, you’ve not made any changes to branch1 for some time. But you consistently commit changes to branch2, including recently.
So you decided to carry branch1 along with the flow. Rebasing branch1 to branch2, therefore, means you’re telling branch1 to ignore its previous commits and inherit the recent commit made to branch2.
Here’s how you can do that:
Switch to the abandoned branch (branch1):
git checkout branch1Then rebase branch1 to the updated branch2:
git rebase branch2Git Squash
Git squash lets you merge multiple commits into one. It helps when you run git commit many times on a single update. A practical example is when each bug fix or code refactor for a single feature has a separate commit.
But you might not want to push the HEAD commit with the accompanying ones as they all have the same purpose. A recommended approach is to squash them into one to avoid confusion when tracking commits.
The best way to squash commits is via the interactive rebase mode. Take a look at the example below to understand this better.
In this example, assume that you have five bug fixes. And there’s a commit for each of them. Here’s how you can squash these five commits into one:
Run git reflog to view the hash code of your commits:
git reflogHere’s the result in this case:
Now your aim is to squash the last five commits, starting with first fix up to fifth fix.
To do that, copy the hash code of the commit just below first fix (0a83962). Then press Q to quit the reflog.
Now run git rebase –interactive on that hash.
git rebase --interactive 0a83962Git then opens an interactive rebase file that looks like this:
To squash the commits, excluding the first fix, replace pick with s for each of the other commits:
Save and close this file.
Another file then opens for you to rename the squashed commit:
Clean those and type in a preferred name for the squashed commit:
Save that file. Then close it and you should receive a success message in your terminal.
Note: The interactive file may open within the terminal. But if you’re on Windows, you might want to force your terminal to globally open files to your favorite text editor to make the squashing easy.
To do that, open your command line and run:
git config --global core.editor "'path to choice text editor' -n -w"Git Fork vs. Git Clone
Forking and cloning are two different terms in Git. You can’t fork your repository as it’s there with you already. You can, however, fork other people’s repository and clone it afterward.
Forking a repository means you’re grabbing a copy of someone’s repository and making it yours. Once you get a copy of that repository, you can then clone it like you would any of your git repositories for local changes.
Here’s how to clone a remote repository on GitHub and initiate a download to your local directory:
git clone https://github.com/username/repository_name.git/Restore a File to Its Default State
If you want to clear the changes in a file after the last commit, you can use the git restore command:
git restore filenameAmend a Commit
You can fall back to a previous commit if you forget to make changes to some files while staging them.
Make changes to the file you forgot. Then use git amend to review a commit:
git add file_forgotten
git commit --amendUnstage Files
You can remove specific files that you’ve staged for a commit using git rm command:
git rm --cached filenameYou can also remove several files at once:
git rm --cached file1 file2 file3 file4Remember to append the relevant file extension to any file you’re exempting. For instance, a plain text file should be filename.txt.
Git Reset
Using git reset is helpful if you want to drop all the files that you’ve staged for a commit at once:
git resetGit reset HEAD, however, points the HEAD of a branch to a specific commit in your working tree. For instance, if you’ve not yet pushed your current commit, you can fall back to the recently pushed commit:
git reset --soft HEAD~1Replace –soft with –hard if you’ve pushed the current commit already:
git reset --hard HEAD~1Git Revert
Unlike the reset command, git revert maintains the integrity of your commit history. It’s handy if you want to amend a commit due to errors or bugs.
It doesn’t abandon the target commit or make a new one. Instead, it reverts to the recent changes you make without deleting or renaming such a commit. It’s a great way to keep your commits cleaner, plus it’s safer than resetting all the time.
To revert to a commit:
git revert HEAD~1Where HEAD~1 points to a specific commit in your working tree.
Delete a Tracked File or a Directory
You can use git rm -f to delete any tracked files in your working tree. Note, however, that Git can’t remove untracked files, as it doesn’t cache them.
To delete a staged file:
git rm -f filenameTo remove a staged folder:
git rm -r -f foldernameGit Logging
To view your commit logs and history in Git:
git logTo log the activities in a specific branch:
git log branch_name
Sometimes you might want to revert to an abandoned commit. So to view abandoned commits, including the relevant ones:
git reflogTo view ref logs for a particular branch:
git reflog branch_nameManage Your Project Versions Like a Pro With Git
With Git offering many advantages, you can manage your project releases remotely without burgling files and folders on-premise in your main branch. Additionally, it lets you run projects easily with a team.
As you’ve seen, Git has many features that you can explore. But be careful to use these features purposefully. Otherwise, you might end up breaking things. That said, you can still spin up a demo remote repository and play around with these features.