- pulling and pushing creates merge commits
- can't pull with local changes
As is already in the mailing list solved here for pulling:
- Code: Select all
git config --global pull.rebase true
(enable automatic rebase of your local commits when pulling = pull and then try to put your local commits on top of that)
let me also add another setting that will allow pulls with local changes (preserving them):
- Code: Select all
git config --global rebase.autoStash true
(combined with the previous setting, automatically stash before pull and automatically stash pop after pull.... stash = a special stack dedicated to storing local changes)
That's it! That solves two most discussed issues! The only remaining issue that I remember from the earlier discussions is that you can't have sequential numerical commit IDs. That a design decision, I'm not knowledgeable enough to explain it properly. Of course, you can try numbering the commits in the commit messages themselves, but of all the Github projects I know that did it, none do it anymore; they've all dropped the approach, probably because it doesn't bring much use.
For me the TortoiseGit is a bit convoluted (especially when compared to TortoiseSVN) for the user while actually limiting the possible options. At work I handle git 95 % of time in the Linux terminal (we only use Git), for my pet projects at home I use GitKraken on Windows. If there is any user info you'd like to know about Git, I can try to answer. I'm self-taught, but can try.
To add a little bit on the weights in favour of Git (as nobody or not many seems to be doing this on the mailing lists) -
- branches are cheap, simple and quick
- interactive rebase is a great tool for coding your stuff now and reorganizing it into better shape later (just before you push/send a PR)
- the inclusion of local repo is ingenious - you can code on the bus or on the plane (or on a conference that has spotty connection)
- you can have e.g. 3 different parts of one file being worked on and commit only one part you want, keeping the rest for later commits (git add -p)
- tons of small projects, but also large operating systems use git as a version control system
My last sentence: Git feels extremely weird and unwieldy if you want to use it like SVN. SVN is outright impossible to use like Git.
There is a learning curve to Git. I only had experience with SVN and it took me about 3 days in Git to learn the basic everyday stuff. There is a great free book Pro Git that can teach you a lot.