This post has originally been published on https://juristr.com/blog/2019/09/resume-work-with-git. Go to juristr.com/blog for more content
Git is an essential tool for every software developer and something you should know well in order to keep your productivity high. Knowing all about git is quite impossible 😃, but there are some basic workflows which will dramatically improve your devlife. Today let’s take a look at how to resume your work after the weekend.
First off, always create a branch
I (mostly) always create a new branch when working on something. The branch is usually just my personal one without anyone else interacting with it. This fact is important as it allows me to change it, rebase it, modify it's commits and "force push" it back up to the origin branch. Without any fear of messing up with any of my colleagues. Such a branch should also only have a single responsibility, in the sense that it only contains things that matter for that feature/bugfix/refactoring whatever. If a work mate passes by and asks me to fix something that’s totally unrelated, then I’ll jump over to master & create a new separate one (or directly commit as per rule mentioned before).
Why? Well,
- it allows me to quickly switch context (features, bugfixes, experiments). If you intermingle multiple features/fixes in the same branch, you have no chance but release them all at once.
- undoing is easy, just delete the branch
- pushed up to the remote, it automatically goes through CI and tests are being executed against the changes of that specific branch
But enough for that.
Back to the topic, resuming work
What do I mean by “resuming work”? Think about the following: you’re working on a feature on Thursday and Friday and you’re not done yet. You push up your branch to the remote repository as usual (just to have a backup copy online in case your computer blows up) 😉.
$ git commit -am 'feat: allow user to save list filters'
$ git push
With that you’re done and ready for the weekend.
On Monday you come back open your code edito...and well...what was I doing again again on Friday 🤔. Happens to you as well? I’m glad 😃. What I usually do then is to…
$ git reset HEAD~
..on the branch I’m currently working. With that command, the last commit on the branch (the one I made before leaving into the weekend) will be removed again and all files and moved back to the staging area. Thus with git status you again see all the files I modified the week before and helps me resume it with ease. Note! This should only be done if the branch is a non-shared one, as you're actively modifying the history of that branch.
Conclusion
As you can see, there's no need to learn all the Git magic. Just some simple commands can already improve your Git workflow a lot. Over the years I've worked with different teams and a lot of developers struggle with Git (although it has been around for more than a decade). As such I recorded a video course that collects a series of git commands that'll directly help you with your daily development tasks: https://egghead.io/courses/productive-git-for-developers
Top comments (10)
I find
git showworks well for me if I want to look through what I last did.git whatchangedis also super useful for seeing a quick overview of the most recent commits on the branch.Oh yes, definitely. Those would be very viable alternatives. With the
git resetcommand you really take out the commit again and you resume your work as if you'd never have committed it. Obviously I don't want to do that always, so thx for those two alternatives people might find useful as well 🙂I always do a branch for any work I’m going to do on a project and commit the code every day to have a backup. I also put this mandatory rule for all team members of my projects. But I always wondered how to get back the history of changes as if the commit were not yet done, thanks for this very useful hint!
🙂 glad you find it useful
Always create a branch is similar to always create a feature switch 👍 that way you will only need 4 commands: pull, commit, push...and sometimes merge
😄 sure, the scope is not to reduce the number of commands though 😉.
Feature flags are a powerful way that help to integrate often and in fact I'm using them as well. If I know a feature will take weeks to develop and it cannot be split up properly into smaller releasable pieces (which would be the preferred way), then definitely go with feature flags.
The scope of this post is more like to resume the work you left the day before, but which you still want to commit and push up to your own remote in the meantime 🙂.
But thx a lot for your comment 🙂
I concentrated too much on reducing the commands used :)
I dunno. I consider a branch shared the moment I push it.
Hey, yes sure, the moment you push it up it is "potentially shared" and everyone can pull it and add commits as well. It's just a matter of conventions. In the teams I've been working on, everyone has his sprint tasks, and its nice to see the progress by looking at remote branches from other devs, but usually you're not going to push to them, unless you explicitly start collaborating.
I think it's all about communication. Also the fact to be able to push your changes up and have CI run tests against it as you proceed with the development of the feature is very nice. I guess those are also the reasons GitHub introduced "Draft PRs" a while ago :)
But that said, those are just my 2 cents of stuff that has been working quite well, in enterprise and open source projects :)