Getting Better at Git: The Advanced Git Workflow
Git is a fundamental technology for nearly every software development team in the world. It allows you to track changes to files, collaborate on a single project with multiple people, and work independently on new features without messing up other people’s work while you’re at it.
Git is awesome!
Most software developers know Git and its basic commands. However, few developers take the time to actually learn how Git works and appreciate some of the more advanced things it can do.
There are times when your project leaves the normal workflow and you need to reconcile conflicts, grab information across branches, or undo/update your commit history. These advanced commands go beyond the normal workflow, but understanding them will make you a more valuable developer.
Git is extremely powerful, but with great power comes great responsibility. In this article, we’ll explore how to get better at Git for those more advanced cases.
The Basic Git Workflow
For most developers, their first introduction to Git involves a predictable basic workflow:
- git pull
- git add <file>
- git commit -m “<message>”
- git push
These basic steps allow you to pull the most recent version of your project, make changes, and then push your changes to the project.
Unfortunately, the basic Git workflow starts to break down when you’re working across multiple branches with other collaborators. You’ll need a more advanced workflow to address some of the challenges of working on a team with multiple branches.
The Advanced Git Workflow
Here’s my more advanced workflow:
1. git fetch
Use fetch to download all the new commits on the remote repo into your local repo. However, fetch will not merge those new changes. You can see the state of the remote repo without being forced to change what you have locally. Additionally, fetch downloads commits and refs across all branches in your remote repo by default, updating refs/tags/commits for all branches of your local repo at once (without merging the changes yet).
2. git checkout master && git merge origin/master
Now we switch to the master branch and update it. In most development teams, the master branch only gets updated once code has been reviewed and tested on other branches, so you shouldn’t be making changes to master locally. This step is identical to running “git checkout master && git pull,” since pull is just fetch + merge. In this case, though, we’ve already fetched, so we can simply merge.
3. git checkout -b <branch-name>
The -b option in git checkout allows you to create a new branch and immediately switch to it. It’s a handy shortcut! You should always switch to a new branch when making changes to the code.
4. git add <file-name> && git commit -m “<commit-msg>”
This is the same as the basic workflow. Make your changes and commit often as you implement the various steps in your bug fix or new feature or whatever you’re working on.
5. git checkout master && git pull && git checkout <branch-name>
We’re going to update master again because something might have changed while you were working on your new feature. Periodically updating master is a great practice, because the sooner you can identify conflicts, the better.
6. Update your branch with changes from master
There’s a bit of a conflict amongst Git users over whether you should use rebase or merge when incorporating changes from your base branch (usually master) into your feature branch.
6a. git merge master
Essentially, merging master will create a more cluttered commit history, as every merge comes with its own commit message. For teams where master is constantly updated, that inflated commit history is undesirable. However, merge is beneficial because it maintains a clear auditable history of commits and it never re-writes changes.
6b. git rebase -i master
Rebase allows you to keep the commit history clean and linear by making the first commit of the feature branch equivalent to the last commit (the HEAD) of the master branch. To do so, it rewrites your project history, which could lead to trouble.
When you rebase, I strongly encourage the use of the interactive (-i) option. There, you can squash unnecessary commits or reword commit messages for an even cleaner commit history.
Learn more about how rebase and merge work and which is the best approach for your team to help you decide.
7. git push –set-upstream origin branch-name
Once we’re done building our feature and we’ve merged/rebased with master, we can push our new branch to the remote repo. From there, we can initiate a pull request and get code review from colleagues on the road to getting the new code added to the master branch and deployed on production.
Get Better at Git
Getting good at Git is key to working on fast-moving, agile projects where things can change quickly. As a developer, Git is likely a tool you’ll use everyday. It makes sense to learn about it and get good at using it. If you do, you’ll find you run into fewer conflicts and are able to contribute more quickly to projects.
Founded in 1991, Intertech delivers software development consulting and IT training to Fortune 500, Government and Leading Technology institutions. Learn more about us. Whether you are a developer interested in working for a company that invests in its employees or a company looking to partner with a team of technology leaders who provide solutions, mentor staff and add true business value, we’d like to meet you.