I recently had to deal with two projects that have a common origin but separated at some point in time. I now had to try to bring them back together again - basically merging the changes. Sounds like a pretty standard
git merge or
git rebase job.
Unfortunately the separation was done in a not so clever way. Someone cloned the original repository, checked out some branch, made some first refactoring steps, got rid of the git stuff (probably
rm -rf .git) and started a new git repository with this status. Rumors are that the situation at that time was so tense that people wanted to make a clear cut - which they did in a technical way.
Quite some time later it was my task to try to get the projects together again. The only input I had was two git URLs and the above story.
Have you ever wondered what kind of patterns
.gitignore allows? Was it
*target*?? Read on and find out!
Just recently I gave a presentation on Git (the version control system, not the British pejorative). I introduced newbies to the Git world and the concepts behind it and demonstrated advanced users some lesser known Git features.
Additionally, I introduced my personal workflow when working on small scale features, let’s say the size of one commit to the main line. Some of my colleagues found this workflow to be particularly interesting, so I’d like to share it here and discuss its benefits and drawbacks.
When working a lot with git knowing which branch you are in is an important information. Putting the branch information in your bash prompt makes this information always visible and also shows immediatly if you are in a folder managed by git.
This is how it looks:
13:46:50 sven@tsui:~/projects/Thruk (master) %>
All you need is a simple function in your .bashrc