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 i...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)