On 2016-05-22, at 9:31 AM, Sharan Basappa <sharan.basa...@gmail.com> wrote:
> Dear Philip, Others, > > Thanks a lot. I have some follow-up questions. > > I am using a simple scenario to get additional clarity. > > 1) I have 4 files in my branch (a,b,c,d) > 2) I modify a > 3) I add a > 4) I modify b,c > 5) I add b,c > 6) I commit > 7) I modify d > 8) I commit d > 9) I push to remote > > Does step 6) above result in single commit object (single SHA reference) or > two? One commit object. That commit object contains (eventually) a full directory tree reference to every file in the project as of that commit. Three files have been changed, so three SHA references are different. Because of that, each node that describes a directory will differ, so everything above that will have a new blob/node describing the files and subdirectories below that. > From a developer engineer's perspective, what does commit signify? Does it > mean something key development is complete? > I ask this question to understand when a developer would do some development > but would make multiple commits. Depends on your workflow. Some people say "commit early, commit often". Some people say "commit when it compiles" I personally do "branch, then commit early, commit often, merge back when it passes tests". (Any given commit on the subbranch will probably compile, but almost certainly has half-implemented features that just won't work.) Some people take this a step further, and say "Do your work on a branch, then commit a single squashed commit of the whole branch". As far as I can tell, not only is there no "one true workflow", trying to figure out what workflow is right for the situation you are in is exceedingly non-trivial, and I have not seen it well-addressed in any of the guides for learning GIT that I have seen yet. > Similarly, if during push step, if it is found that remote is ahead of local > (and most likely requires merging) then does it mean anything wrt to the > already computed SHA? > I assume that already computed SHA has no meaning. I am not the person to ask here. My pushes only go to a repository I work on. I would *love* to see a good writeup on how to manage, and contribute to, a repository that will accept updates from many people doing pull requests, letting you update as the master does, without losing your own "features in progress". Yes, this is supposed to be git's area, but trying to understand from the docs how to manage it, especially if it later turns out that the "upstream master" is going off in an incompatible direction, and you want to take over managing a fork that is doing something else, and accepting pull requests from others. It doesn't help that as far as I can tell, "Pull Requests" are actually things that Github and Bitbucket do that are not in the core base git. --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
