If I cannot remember what I did, I usually
$ git branch -lto see what I was working on
- use a diff against the last commit in my local repo and work on / commit with a useful message
- if I still dunno what I did
$ git reset --hard && git pull
- work on
If you cannot remember what you did, your changes are probably not important anyway. If your team has even made "huge progress" after "you have been away for a while" while not needing your commit, your contribution was probably not necessary either or already implemented by someone else.
Never commit stuff you do not understand. Never commit untested changes. Ideally, implement review and CI processes for pushes and pull-requests. Also try out a sane git branching strategy, using feature branches, so you at least know what you were working on. I really like gitflow , but depending on your situation, there are other good strategies as well.
When writing a commit message, I usually use a verb as the first word followed by the content, for example
$ git commit -am "implement .abc file format for asset loader" $ git commit -am "fix #123" $ git commit -am "add package.json" $ git commit -am "remove foo as a dependency"
Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!
💬 Ask programming questions without being judged
🧠 Stay in the loop and grow your knowledge
🍕 More than 500K developers share programming wisdom here
❤️ Support the growing dev community!
2 things ...
- you should never commit what you don't understand.
- you write in the commit message what the changes are.
there are different philosophies ... I write in present tense
#ticketNr <summary headline> - does blabla - change blub - add moo as an example #1337 implements new menu endpoints - adds role model and references - adds new backend for menu customization - changes parts of the user model
If your company uses only sort of project management or ticketing system, you could leverage that. I use the GitFlow branching strategy. So when I start working on a new feature, I'll make a feature branch which I name with a ticket number. Example:
features/BRB-247. When the branch is named in this way, you can refer back to the associated ticket to remind yourself what you were working on.
The Dev Community
(Free, friendly and inclusive)
A network for software developers to learn new things and get insight into the world of programming