It's always seemed worthwhile to me to dig into git's model more, but if you're already comfortable and productive with stuff like detached head/rebasing/basic workflows, it's hard to justify when you're already trying to find time to learn new languages, frameworks and devops tools ...
git add -A
git commit -am "fixed some stuff"
but I've finally found some time to start digging into how to really use it.
The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.
Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story.
Use 'gitk --all' to view the tree of changes. get comfortable with using feature branches, using interactive rebasing to clean up a messy history of changes, etc.
The CLI works great for most things but visual tools make it much easier to write a clean history and reason about the changes over time.
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %C(magenta)(%cn)%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative --left-right
It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc).
The CLI is the ideal too for a lot of things. Preparing commits is not one of them.
Having said that, I stage all my commits on command line, and generally go to a GUI rarely for certain visualization tasks.
I also do this. :|
I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.
* git add -p, git add -i are nicer ways to add files
* git grep
* git reset, revert, and checking out old commits
- these commands I currently find tough to get right
- this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff
Most of this stuff is stuff that I've known about since I started using git but I was afraid to use it because I didn't really know how it worked and didn't want to "mess up". Since the previous comment describes 90% of what I need to do, there wasn't really any point to doing it any differently.
The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. This leaves the obnoxious necessity to commit for just syncing things instead of for actually finishing a feature. I don't want to do rebasing because I don't want to lose history. This is the main reason I don't think git is currently an ideal solution for me but since I have nothing better I'm stuck with it.
It needs a simple semantic interface and it needs the ability to "sync" in-between commits.
git checkout -b wip-syncing
git commit -m "wip means work in progress"
git push <whatevs> wip-syncing
git fetch --all
git checkout <whatevs>/wip-syncing -- .
git push <whatevs> :wip-syncing
In general, you're going to be fighting against git if you take an absolutist stance against rewriting history. Which is fine! But a little bit of controlled rewriting can open up a lot of options.
Edit: and I'm typing this from memory on my phone so please don't copy and paste the commands without verifying that they work correctly first!
Could you use something like rsync or unison to sync the working directory (including the .git directory) between your desktop and laptop? I'm new to git myself, but after reading through the OP article I imagine this would work.
also, learning to be quick to create (and dispose of) branches, as they're just names.
You can just do "git stash list".
It is a great way to have a clean linear history.
But it makes git pull 'illegal' because it does a merge implicitely.
That's tipically something I didn't think about the first times I used git.
Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead:
- The fundamental unit of code review is a branch.
- Review feedback is incorporated as additional commits to the branch under review.
- The verb used to commit to the trunk or other release series is 'merge --no-ff'.
Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.
I see merits in both approaches: Rebase seems to be good when you want to focus on the project minus the process, while merging seems to be good when you want to know the process behind the project. For larger projects with multiple contributors, I think the merging approach is better because of the process visibility. For smaller projects with one or two developers, a rebase approach could be "cleaner" when looking through the logs later on.
I'm interested to hear what other's opinion on the topic as well.
 - https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase...
In my experience, the clean linear history can be important when you build a product which is going to be certified since the developement process is key to obtain the certification.
Also, I like the fact you can always reorganize your commits before rebasing, making them more atomic / cleaner.
git pull --rebase
git config --global pull.rebase true
git config --global pull.rebase true
git config --global branch.autosetuprebase always
I think it is slightly more relevant to understand the model than the .git/ structure since the .git/ folder is just an implementation detail.
> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
Somehow I do not see this mentioned often despite it is, in my opinion, hands down the best tutorial for git. Not too short, not too long, not too simplifying, not too complicated. Just right.
The article rings a lot of bells because I actually do understand how Git works. I'm not so sure it is understandable by someone who is new to git.
The second sentence of the actual tutorial part: "When you create a git repo, using git init". I'm sorry, what is a repository? Some sentences later: "Here is what’s your .git will look like before your first commit:". What is a commit exactly?
I once read another tutorial, which I can't find now. It reads as a story of a group of people exchanging files and in order to avoid administrative mess, eventually end up inventing the core of git, because it solves their problems. I think that tutorial is much better for explaining the concepts of git to beginners.
Edit: I think this is the tutorial i mentioned: http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
THe problem with git is not that it can't do those things, but that it is hard to attain mastery of git commands even if you know what version control is supposed to do.
I found it to be an enlightening talk and it helped me understand git better than what I had until then.
It was a couple of years ago, so it may be even better now.
Thanks for posting it. I always had a really hard time trying to track down the link.
You say I have very little excuse for my ignorance, but I would also say that I have very little excuse to spend any more time learning a tool with as many dark corners as git.
If you're about to do something 'weird' like fix a merge conflict, you can save the changes by creating a branch.
Sometimes you have to go back and fix a previous commit to reconcile a conflict. The 'gitk --all' command is your friend here. With it it's easy to visualize the history, reset, cherry-pick commits, etc.
Can we, please, take this as an indicator that Git is too fucking complicated? After the first thousand "Git made easy" blog posts it should have been apparent.
It has _NOTHING_ to do with meeting needs or doing things spectacularly better than other tools. There was version control before git and it worked just fine. I just think some "cool kids" started using it, it developed a certain Caché that made it desirable and that was it: here we are with the most popular version control system in the world with an absolutely shitty, inscrutable interface.
For the vast majority of git "users", this doesn't matter. They use git as little more than filestorage.
I personally think git is fucking awful.
... but it's the best version control system anyone's come up with so far. It sucks less than the alternatives and I use it for all my projects.
Git might qualify as best FREE version control system anyone's come up with so far. But best? No, no I don't think so.
No way it is the best. I think Mercurial easily holds the winning position for the version control with most power to weight ratio...
Open Source will probably never produce a good centralized VCS because it's not a problem that exists for Open Source projects.
I agree with the author that understanding how Git works is the only way to get comfortable with it. For eg, Rebasing is hard but you will have your "Aha!" moment when you realise that it is nothing but a combination of hard reset and cherry-pick
How Git works can be easily drawn out on paper to explain it to someone. The branches, commits and merges is simple to draw.
When we lose sense of our state we always take a piece of paper and draw it out. Most of the time you can just figure it out what's up.
It came to the point where I thought about spending a week just learning git to defend my berd creds.
Instead, I just use a gui for anything beyond add/comit/push. I still don't like not to understand one of my daily tools, but I have real work to do.
git status will tell you how to throw away local changes, btw. Depending on the kinds of changes (e.g. edit/delete added, staged or not) need different commands.
If you start with git, you won't have a clue where the interface ends and the implementation details starts. Which is why, I think, people find git hard.
I still hope that the whole development world will come to their senses and start using Mercurial more and more...
This one really helped me in the beginning. Visualisation in general helps when learning git (branching, rebasing etc). Ungit is my goto when I want to just see how it (repo) looks like.
Anyone knows what would be most usefull outside the scope of the tutorials above?
Knowledge is Power: Getting out of trouble by understanding Git by Steve Smith 
As a meta note; it can be really difficult to keep up a continual blog series. It helped that I advertised it in advance and then wrote around two in advance so that writers block or holidays didn't impact the schedule.
However, after some digging it turns out that Pluralsight put it under a Creative Commons license, so the git guide I think that you're talking about seems to be availible on Github.
you can put the files you don’t want git to deal with in your .gitignore file.