Talk:Using Git

From BioPerl
Jump to: navigation, search


git merge/push troubleshooting

Chris, could you double-check about that troubleshooting block you moved? -Dave Messina 15:34, 27 May 2010 (UTC)

For me the merge command was clean, which makes sense I think since that's a local command and doesn't look at the remote repo. It wasn't until I tried to push that I got the error:

$ git merge topic/davemessina-multiphylip
Updating 95025c0..b8ae20c
 Bio/AlignIO/ |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)
$ git push 
 ! [rejected]        master -> master (non-fast-forward) 
error: failed to push some refs to '' 
To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

Developing as a non collaborator?

Hi, I'd like to clone BioPerl from github, develop code, then push back changes (correct words there?) onto a project in my own github account. From there BP devs could get the changes from my project and merge them with the BP project.

How do I push my changes back onto a project for my user on github?

Cheers, --DanBolser 12:49, 8 July 2010 (UTC)

Fork it

Dan, you generally should do this by (1) logging in to GitHub, (2) going to the main BioPerl github repo and forking the repository, and (3) checking out the forked code from your local account. The process is described here. --Chris Fields 18:02, 26 July 2010 (UTC)

Helping a noob...

04:35 < kai> <-- is 
             my explanation of rebase I gave in #bioperl a while ago

04:37 < kai> ok, so here's how I work on bioperl..

04:37 < kai> git clone
04:38 < kai> that gives me the local clone with the "upstream" bioperl
             repository as "origin"

04:38 < kai> cd bioperl-live; git remote add repo 
04:39 < kai> that adds my fork of bioperl-live as remote "repo"

04:39 < kai> if you don't have commit access to the official bioperl repo, you 
             need to clone from git://
04:40 < kai> the rest of the setup remains the same, after all you of course 
             have commit access to your own fork
04:40 < kai> you'll have to use your github user name of course

04:41 < kai> now, when I want to work on a new feature, I create a feature 
             branch, like so:
04:41 < kai> git checkout -b my_new_feature origin/master
04:42 < kai> this creates the new branch "my_new_feature", branched off 
             whereever the official bioperl-live repository's master branch is 
04:43 < kai> the checkout command I gave also changes to the my_new_feature 
             branch right away
04:44 < kai> now I just do my coding, git add the changed/new files and git 
             commit them

04:47 < kai> to push my changes, I use my "repo" remote, which as you'll 
             remember is my personal fork of bioperl-live
04:47 < kai> git push repo my_new_feature

04:48 < kai> now, let's make things a bit more complicated, so I'll go and set 
             up another box for development as well

04:49 < kai> first steps, same thing as before, git clone 
   ; cd bioperl-live; git 
             remote add repo

04:50 < dbolser> so how come you don't just clone kblin
04:51 < kai> I like the convention that "origin" always is the "official" 
             repository, and "repo" always is my personal repository

04:50 < kai> now, I'm still sitting on branch "master" of my local repository, 
             but I want to work on my_new_feature, so I need to create that 
             branch locally

04:50 < kai> git checkout -b my_new_feature repo/my_new_feature

04:52 < kai> by creating the branch based on repo/my_new_feature, this is the 
             same as on the first box

04:52 < dbolser> OK, so it's like you go home to continue work on the feature 
                 you started at work

04:52 < kai> yeah

04:53 < kai> there's nothing stopping you from doing "git checkout -b 
             my_new_feature origin/master" and creating a new branch with the 
             same name as a branch you have in another repository, but that 
             gets confusing as hell
04:54 < kai> ok, so let's say I had a brillian idea at home and committed that 
             to my personal github fork by doing "git push repo my_new_feature" 

04:55 < kai> on the next morning at work I obviously need to update the 
             checkout on my work pc
04:55 < kai> and now here's where things get a bit confusing. (there's more 
             than one way to do it, perl hackers should like this)

04:56 < kai> git remote update
04:59 < kai> basically it's a shorthand for "for every remote configured do 
             'git fetch remote'"

04:56 < kai> git rebase repo/my_new_feature
04:57 < kai> git remote update grabs the updates from all remote repositories, 
             so from "origin" which is the official repo and "repo", my 
             personal fork

05:02 < kai> an alternative approach would be to use "git pull repo 

05:03 < kai> but that won't make sure your copy of "origin" is up-to-date, so 
             you'll miss out on those changes if you create a new branch off 

05:11 < kai> assuming you're "done" with your new feature and now want to push 
             it to your "master" branch (doesn't relly make sense on your 
             personal fork, but let's assume you have commit rights to the 
             official repo)
05:12 < kai> in order to be able to push, you need to be up-to-date in your 
             current branch, so "git remote update; git rebase origin/master" 
             takes care of that
05:12 < kai> git log (or gitk) helps to check that there's no temporary or 
             simply wrong commit in your local branch

05:13 < kai> now you can push to the "master" branch of "origin" like so: git 
             push origin my_new_feature:master
05:14 < kai> that will push changes from the local branch "my_new_feature" to 
             the remote branch "master"
05:14 < dbolser> if you don't have commit, would you just ask someone to review 
                 your branch?
05:14 < kai> yeah
05:14 < kai> that's why rebase is handy as well, keeps all the "for review" 
             commits on top of the history

05:15 < kai> there's only one catch. if you rebase your work tree and there are 
             new commits you rebase on, a plain "git push" to your personal 
             fork will fail
05:16 < kai> that's because the history gets rewritten on a rebase and the 
             remote branch doesn't match
05:17 < kai> however, you can tell git push to overwrite the remote history 
             using git push repo +my_new_feature

Random Notes: Ammend a commit

To amend a commit before pushing onto a remote, try one of the following:

10:03 < dbolser> how to edit a commit message before pushing onto a remote?
10:03 < ciaranm> dbolser: git commit --amend or git rebase -i
Personal tools
Main Links