If your "simple" explanation of how to use something is 27 pages then it is many things and simple isn't one of them.
My favorite thing about Git is how it's forced Perforce to add features and lower price. Thanks Git!
Git concepts simplified
111–120 of 142 posts
Re: Git concepts simplified
#112Earlier quoted context omitted.
It is simple because a simple explanation is possible. Simple doesn't mean "intuitive to proverbial grandmother". Git is clever, moderately novel and therefore unfamiliar (depending on your background), and simple . There are not many concepts present, and the concepts that are there are not difficult to understand, but those concepts need brief introduction because they are concepts that many will be unfamiliar with…
That's not the strongest argument. If you want to get anything done at a reasonable level, checkers is hard (American checkers is easier than international checkers, but neither is really simple). Git may well be similar: relatively simple rules, yet hard to use proficiently.
Checkers is a very easy game, but with those incredibly simple rules you can get complex behavior. For an even more extreme example, you can look at Go. Git is similar, except there is no competition/competitor there to befuddle you. From the simple components/rules (you've got what, you can perform incredibly complex operations that are infeasible with lesser VCSs.
Simple rules/components, complex gameplay/capability.
If you want to play it simple, git does that too.
Re: Git concepts simplified
#113Earlier quoted context omitted.
Well, I'm being a little facetious. I do understand what the index is and what it's used for (but not why it's called the "index" instead of, say, the "stage"). What I don't understand is why the index exists as a separate abstraction. You could have the exact same effect by, for example, doing a git stash, and then popping changes out of the stash into your (now clean) working directory. The WD in effect plays the r…
I'm not sure I see how you could use `git stash` to accomplish the same thing. Running `git stash && git stash pop` is almost a no-op, so you don't get the benefits described above. Am I missing something?
I thought you could pull individual files out a stash, but it seems I was wrong about that. But it's not hard to imagine a variation of git stash that allowed you to select individual files from a stash to pull back into your working directory.
Re: Git concepts simplified
#114... that is not simple. But I'm figuring it out anyways. I commit my changes to my own repo and keep building changes under HEAD, committing as I go. If I get a branch from a buddy and I want to add it to my code, I either merge or rebase depending how I want his commits to be intertwingled. Because GIT is decentralized, there's no difference between merging in a buddy's branch, and import the latest changes from Ori…
> The decision of when to merge vs. rebase is still confusing to me.
I'll take a stab at this. When you merge, you're merging their branch into yours. At the end of you have both pieces of code, but all the history is still there. You can see that their branch started 20 commits ago, that two things were done in parallel, and that they came back together with the merge.
Rebase is a different. Rebase changes history. Rebase is like this:
1. Find the common ancestor between the branches
2. Extract each commit from their branch, turn it into a patch (named patch*N*)
3. Switch back to your branch
4. Apply patch1, patch2, ... patch*N* in order
It makes sense if you think about Git coming from kernel development. Developers tended to work in patch sets, a long series of patches to a common base. Rebaseing is just applying that series of patches to a different base.
Merging merges branches, but rebase is more like moving branches.
Re: Git concepts simplified
#115Earlier quoted context omitted.
One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally. Regarding merge vs. rebase, here's my approach: rebase to keep history a straight line when it's just your changes and it's just a few commits. If it's too many commits y…
> One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally. But then what happens when I merge/rebase locally and publish at the same time as somebody else? I assume the origin doesn't keep a lock on the whole mess while I'm doi…
> I assume the origin doesn't keep a lock on the whole mess while I'm doing my local merge/rebase.
You're right that the remote server has no idea what you're doing on your local machine.
> . That sounds like it would lead to a "last-one-wins" conflict-resolution or a complete reversion of the origin if I publish without rebasing on the origin's version first.
Unless you use a --force option, Git will refuse to do anything that will lose information. When the second person pushes, Git will say "You can't get here (new commit) from there (their commit). Nope." In that case it's up to you to pull their changes and either merge or rebase your changes. At that point when you push your new commit will be a descendent of the server's latest copy, and it willy happily accept it.
Now Git's messages aren't that friendly. The message you'll get is something like 'Unable to perform a fast-foward merge'.
Re: Git concepts simplified
#116Earlier quoted context omitted.
Are you using gitflow? https://github.com/nvie/gitflow So yes, if you try to push without pulling down changes, then you will get an error about the histories having diverged. Sometimes you don't care about wiping out history, and can just push with the -f parameter, but most of the time that's your cue to rebase. Branches are cheap in git, and there's no real advantage to doing dev work in the master branch. You sho…
I'm not using git at all , I'm trying to understand how it works before I start. Every guide to git I read before was a completely opaque mess of terminology, so this is the first time it's starting to make a lick of sense.
I think Git is much easier to understand if you understand the underlying data model. The core object in Git (as far as you need to care) is a commit. Each commit holds a link to the commit(s) it was based on. If two commits have the same parent, you have two branches. If one commit has two parents, it's a merge. Individual commits don't know what branch(es) they are a part of.
Branches are just pointers to commits. When you make a new commit on a branch, the new commit is saved and the branch pointer is moved forward to point to the new commit.
Tags point to branches, but they don't get updated. They're supposed to be permanent (but can be modified if you try). If a tag points at a commit and you make a new commit, the tag still points to the original commit.
The only other odd term would be HEAD, which is like a branch that ALWAYS points at what you have checked out at the moment. You'll see this if you make commits without being on a branch (say you checked out an old commit and just started working).
Since branches are just pointers at commits, you can move them around easily. If you make 6 new branches, they all just point at the same commit to start, which is why it's so amazingly fast to do. If you want to undo a commit (that you haven't pushed), you can move the branch pointer to a previous commit. After that when you make new commits it will be like the mistake never existed. (Note: If you accidentally do this, it can be fixed if you catch it soon enough).
When it comes to using branches, "A Successful Git Branching Model" [1] is very commonly used, and works fantastically. I had almost no trouble getting the other developers in my company on the model, and it makes it very easy to keep things straight.
If you'd like help understanding Git, I'd be glad to try to help you. My email address should be in my profile. You may find this kind of thing much simpler if you look at the graph of repository. My company uses SourceTree[2], which is a pretty great GUI and makes it easy for me to see how the various branches I've got relate.
[1] http://nvie.com/git-model/ [2] http://www.sourcetreeapp.com (Mac & Windows, Git has a basic gui command built in if you want)
Re: Git concepts simplified
#117... that is not simple. But I'm figuring it out anyways. I commit my changes to my own repo and keep building changes under HEAD, committing as I go. If I get a branch from a buddy and I want to add it to my code, I either merge or rebase depending how I want his commits to be intertwingled. Because GIT is decentralized, there's no difference between merging in a buddy's branch, and import the latest changes from Ori…
> The decision of when to merge vs. rebase is still confusing to me. i always thought it was "never rebase commits you have pushed" at least you know about rebase though. :)
That is certainly the rule 99.99999% of the time. It's possible, but it can be a mess for everyone else.
Before you push, you can choose to do it either way.
Re: Git concepts simplified
#118I don't use Git and would like to know how the following problem is solved in Git. Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is o…
> (having sources which are compiled in different base directories) With my nascent Git understanding, I think you would just have multiple branches for v1, v2... and then clone the repository multiple times so you have multiple working copies. Check out v1 in the first one, v2 in the second one. Although changing between related branches is usually quite quick in Git. Also, a fresh checkout of ~100mb is not a lot. A…
> and then clone the repository multiple times so you have multiple working copies.
This is probably not what you want. First, you should know that switching between branches in Git is insanely fast. In general, it won't get in your way.
If you clone the repository, each one is a full git repository. That means you'll triple the storage on the disk. Worse, you'll have to do 3x as many pulls to keep all 3 repositories up to date.
> You're rarely developing two things at once in any given instant of time... why not just quickly check out the branch you want?
It often comes up, but that's what we do. We may have a dozen branches on our machines (the thing(s) we're working on, recent things we worked on, the one that's been sitting for a while we're waiting on an answer to pick up again) and we can switch our project within a second or two on a simple rotating hard drive.
Re: Git concepts simplified
#119I don't use Git and would like to know how the following problem is solved in Git. Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is o…
A Successful Git Branching Model [1] is a very common way to deal development in a good sized project. You could consider the bug fixes to v1, v2, and v3 to be hot fixes. You could choose to keep a single running branch (the equivalent of master in the model given) for each of the older versions if you keep adding occasional features.
I know I've seen guides online of how to deal with the exact problem you're describing, but I can't remember where to find any of them right now.
Re: Git concepts simplified
#120There seems to be ALOT of 'Git Explained' stuff. The best way to learn Git in my opinion is start using it! Google stuff as you go.
True, but even after travelling along the RCS->VSS->CVS->SVN graph for the past 20 years I still find git baffling sometimes. I like it but the question is whether I want to invest my brain resources, which are a scarce resource at age 47, in learning a revision control system that can drive you into a cul-de-sac when using even the most basic workflow. I think git!=simple but I applaud the effort.
The model behind Git, the way the repository works/conceptual model, is incredibly simple. The only trick is learning which commands are used to make the changes you want, and that can take a little time (and Googling).