Git workflow questions

[ThomasBush]

I had a few of a workflow questions about Git, GitHub and branches. When I go to add/work on a new feature in my git repo I create a new branch for this code. I write my code, push my branch. I get a notice that this branch doesn't exist which also contains the code to push it. I assume this is controlled through my push strategy in my gitconfig, but this is still a bit confusing to me.

[push]
  default = simple 

Would a different push state allow me to avoid this minor annoyance. Also, what does the workflow look like after you merge a branch.

Currently, I would push my feature branch up, open GitHub in a browser, make a pull request and merge. I am then given the option to delete the branch, which I usually choose to do. Next I would navigate back to the command line, check out the master branch and pull.

This process removes the branches as far as GitHub is concerned, but leaves me with multiple old branches on my local machine. Would I just delete these branches in the command line? Sorry there are a lot of questions here. I understand that a work flow question is a matter of opinion, but I want to understand how those who use Git/GitHub on a daily basis would recommend.

It's been very rewarding thus far using branches as it seems to clear out all merge conflicts which cause me to panic. I would like to be able to contribute to things eventually, like open source, but am not quite comfortable enough to get there. Thanks!

[billgathen]

Since we use a private company repo for Adtegrity stuff, we do all of the above from the command-line.

Since it's a GitHub repo you own, you can skip the GitHub interface and pull requests entirely, do all your work in pure Git at the command-line, to keep from switching contexts.

Here's my workflow for adding a feature:

• git checkout master # start from the master branch
• git checkout -b new_feature # creates a new branch from master called new_feature and switches to it
• ...implement part of feature...
• git commit -m "Getting there" # this goes onto the local new_feature branch
• ...implement rest of feature...
• git commit -m "Feature complete" # also on local new_feature branch
• git checkout master # switch back to master branch
• git merge new_feature # Merges new_feature branch into master
• git push # pushes updated master branch to origin: in your case, GitHub
• git branch -d new_feature # delete local branch

You don't need to push your feature branches to GitHub at all, unless you want them backed-up on their servers because you're concerned about dropping your laptop or you want someone else to be able to work on it from their machine.

If you're trying to contribute to someone else's project, then you'd push the branch out as you have been and they'd use pull requests to pull it in. Vice-versa if someone else is contributing to one of your projects.

Hope that's helpful. An excellent tips-oriented resource for git is GitReady. Definitely check it out.

[ThomasBush]

@billgathen, really helpful stuff here. I appreciate the time to lay that all out, makes more sense. I will take a look at GitReady, Thanks!

[billgathen]

Hope it helps! Let's leave the topic open in case it can help someone else.

[thejbsmith]

I know I'm jumping in a little late on this, but take a look at git rebase as well. Many people will tell you that git rebase should be used instead of git merge, but it is really a matter of opinion. Simple explanation, git rebase will replay your commits on top of the destination branch, preserving all of your commits. git merge will merge all of your commits to the destination branch, and will leave you with a merge commit.

Do a little bit of research on both, and make your own decision. I use rebase most of the time so I can preserve the commit history, but in the end it will be your call, or the call of the company you work for.

Hope this helps!

[atkolkma]

Thanks, guys! Very useful tips.

On Mon, Dec 23, 2013 at 9:17 AM, Jim Smith notifications@github.com wrote:

I know I'm jumping in a little late on this, but take a look at git rebaseas well. Many people will tell you that git rebase should be used instead of git merge, but it is really a matter of opinion. Simple explanation, git rebase will replay your commits on top of the destination branch, preserving all of your commits. git merge will merge all of your commits to the destination branch, and will leave you with a merge commit.

Do a little bit of research on both, and make your own decision. I use rebase most of the time so I can preserve the commit history, but in the end it will be your call, or the call of the company you work for.

Hope this helps!

— Reply to this email directly or view it on GitHubhttps://github.com/WestMichiganRubyTraining/discussion/issues/48#issuecomment-31121092 .

[ThomasBush]

Thanks @thejbsmith I will look into this as well. I appreciate the help!