Andrej Mitrovic wrote: > What the duck has happened to this topic? > > Ok anyway, I found out a few things: > > I can change $HOME by adding this line into C:\Program > Files\Git\etc\profile file: > HOME="/d/dev/git/" > > right *above* this line: > HOME="$(cd "$HOME" ; pwd)" > > This was from someone's blogs post. And then if I want to start git > bash from a different initial directory I just change the git bash > shortcut "Start In" field to whatever directory. > > Anyways I've made a bunch of commits to my forked repo of dpl.org, and > now have to figure out how to make a pull request. I haven't made any > branches or anything because I'm way too new to this. > > I would also like to know how to uncommit a change which hasn't been > pushed yet. So if I locally do: > git add someFile.d > git commit -m "woops wrong comment"
I recently starting using interactive rebasing which is a tremendous help for these kind of situations. This is usually what I do: start a branch for work on feature foo: git checkout -b foo * do a bunch of commits on foo * update master with newest changes: git checkout master git pull when foo is done, rebase it on top of master: git checkout foo git rebase -i master This will popup your editor and let you squash some commits together and edit the message. The text in your editor is fairly self-explanatory. It also 'replays' the commits on top of those from master you have pulled in *after* creating the foo branch. This helps with two things: you can resolve any conflicts inside the foo branch and prevents annoying merge commits. It will look in history like you have starting the foo branch from the latest commit from master. Sometimes this is not what you want, but most of the time it makes sense. >From here you can either merge it with master (it will fast-forward) and push to github, or push the foo branch to a foo branch on github. Doing interactive rebasing like this allows you to organize the series of commits and messages *after* you are done developing something, resulting in very nice pull requests. There is one thing you should never do: rebase a branch which you have already pushed to some place other people can see / use / depend on. Then you are taking away the history on which people have build. It is to be used strictly with private branches. I use this workflow to work concurrently on lot's of different topics, each in a seperate branch. Without rebasing the history will be cluttered with merge commits. I also don't have to worry anymore about other people when I commit, since making nice messages and such is postponed to the point of a rebase. This makes life much more pleasant.