gistfile1.txt

1. Rebase Git workflow

When you’ve finished a feature on a local branch and it’s time to commit your changes to the master branch, you might prefer merging over rebasing.

I used to be in a team responsible for merging sprint features into the master branch. This was a nightmare. Always.

Another dev taught me an excellent Git workflow that combines rebasing and merging when it’s time to commit changes to the master branch, and it has honestly made such a difference to my workflow.

With the rebasing and merging combo outlined below, merge issues are kept to a minimum because your local history will match master before the final merge into master. No headaches! (Or just mini ones!)

Rebasing also means working in a linear approach where local changes are added at the end of the branch. It makes it so much easier to read the log and find out exactly what’s happening.

Here’s the rebasing workflow:

Checkout master: 
git checkout master
Make sure master is up to date: 
git pull
Checkout feature branch:
git checkout feature-branch
Rebase master:
git rebase master
If you encounter a merge issue, open your merge tool:
git mergetool
Fix merge issues
Continue with rebase:
git rebase --continue
If you encounter more merge issues, follow Step 5-7
If you make a mistake while merging, abort the merge to discard all changes you’ve made, effectively going back to Step 3:
git rebase --abort
When you have nothing left to merge, push changes to the remote feature branch:
git push -f
After your changes have been reviewed and approved, merge to master.
2. git add -p

When you’re working on a local feature branch, do you sometimes want to pick out code changes you want to commit, but leave other changes uncommitted? With the git add -p  command, that’s exactly what you can do.

Before I learned about this command, I inefficiently discarded changes I didn’t want to commit using git checkout — src/etc  and then committed all changes git commit -A . What a waste of time.

Now, I use this command when I have certain variables only applicable to my local environment that I don’t want to commit or when I have a piece of code I’m still working on but want to test a completed piece of functionality in another environment.

This command is the single most useful command I’ve learned in the last year (thanks, Callum!).

3. Keeping your branches tidy

Rename branch

Coming up with pithy branch names is definitely up there with naming variables. Sometimes, I’m working on a feature branch and come back the next day trying to understand why I picked such a generic branch name that probably already exists in the remote repository.

The command to rename branches locally is something I use at least once a month and is super quick and useful.

Rename a branch while currently not in the branch to be renamed:

git branch -m oldName newName
Rename the current branch:

git branch -m newName
Easy.

Delete old local branches

Check all your old local branches right now: git branch 

If you’re like me, you might have over 10 stale branches that have either been merged into master already or are just sitting around taking up space.

Time to delete this baggage. But only if you’re absolutely sure you don’t need them anymore.

git branch -d branchName
4. Git reset-hard

Do you sometimes just mess up on a local branch and want to abort all changes? Me too.

The git reset –hard  command wipes all your staged and uncommitted changes so you can start again.

Be careful! As with most Git commands, you have to know exactly what you’re doing. This is a great resource to understand the inner workings of this command.

5. Escape greater than symbols:

Drowning in your current Git workflow? 

If you’re using PowerShell for Git (such as posh-git) you might encounter the ever annoying double greater than symbols >> that are impossible to escape unless you know the command.

The answer: C 

There are always easy ways we can improve our Git workflow. A few commands can make all the difference between saving time and getting frustrated over merge conflicts that could have been avoided.

Version Control Best Practices

Commit Related Changes
A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other team members to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

Commit Often
Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard both to solve conflicts and to comprehend what happened.

Don’t Commit Half-Done Work
You should only commit code when it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s “Stash” feature instead.

Test Before You Commit
Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing / sharing your code with others.

Write Good Commit Messages
Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation? Use the imperative, present tense („change“, not „changed“ or „changes“) to be consistent with generated messages from commands like git merge.

Version Control is not a Backup System
Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see “related changes”) – you shouldn’t just cram in files.

Use Branches
Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, experiments, ideas…

Agree on a Workflow
Git lets you pick from a lot of different workflows: long-running branches, topic branches, merge or rebase, git-flow… Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates’ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.