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