There's new GIT instructions on Github now
Lutger Blijdestijn
lutger.blijdestijn at gmail.com
Sat May 21 04:46:21 PDT 2011
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.
More information about the Digitalmars-d
mailing list