Help me use git the way it was intended.

July 8, 2012 12:59 PM

I'm finally using git. Right now I'm using it stupidly: I pull from the main branch, make changes, push the changes, and then deploy. I'd like to be smarter with this process, and in particular, I'd like to be able to have (1) a process that can handle changes in priority easily and that (2) includes a clear separation between code that still needs to be tested vs. code ready to go live.

For example, several times now I've been working on a feature and then had an unrelated bug that needed fixing. Right now that requires me to do a stupid dance with my commits and deployment that isn't really optimal or sane.

My understanding is that really, to do this right, I should be creating a new branch, work on the feature, and then merge when it's done. If something crops up that needs to be addressed on the main branch, I can go ahead and fix it there, ignoring the feature branch. Then any conflicts are dealt with during the merge process.

I also believe that I should be running a testing branch for all changes, and then syncing everything to the live branch once it's good to go. Right now I just deploy the main branch to a dev server, make sure everything is OK/approved, and then deploy the same (only) branch to the live site.

I'm primarily using tortoisegit on windows, but I am not averse to command-lining it up. Actual development takes place in Linux VMs, so linux-only advice/processes are totally fine. Caveat: If I'm going to be comparing diffs and selectively choosing which portions to keep and which to discard during the merge process, it does seem that a GUI with highlighting and whatnot would make this much simpler and clearer than on the commandline. So that might be worth keeping in mind, unless I'm wrong wrong wrong.

I'd like to go slowly with this: do one small thing a better way for a few commits/features, get comfortable with it, and then add more complexity at that point rather than trying to adjust to a drastically different process all in one go. I want to keep my productivity high during the entirety of this switch to betterness.

Which new processes need to be added to my workflow? What order should I start making these changes in? Tutorials advice etc? Sections of the manual that I should RTF out of?

Thanks.

posted by jsturgill to Computers & Internet (12 answers total)

The great thing about git is, there is a way to do what you want, and probably more than one way. I found the biggest change to my workflow was: commit early and commit often. Just started a big refactor but aren't done yet? commit! Now it's a little better? commit again! And now the tests work too? Final commit! But wait, you say, now your history is all crazy. That is where git rebase -i comes in. This command lets you reorder or smush together (among other things) your commits, so your history can look however you want it to. As long as you haven't pushed yet!

New branchs are super easy: git checkout -b branchname will just make a new branch that looks exactly like your current state*. So if you have 3 commits on Big Feature that aren't ready to go, and you haven't made a branch yet, but need to bug fix:

git checkout -b BigFeature
git checkout master
git reset --hard origin

and you can now make your urgent bug fixes on master.

Also I found getting to know git status and git log was super informative. My favorite alias is log --pretty=format:'%Cred%h%Creset %C(bold blue)<>%Creset%C(yellow)%d%Creset %Cgreen(%cr)%Creset %s' --abbrev-commit --date=relative

* When you want to know whether state means working branch, stage, etc, read http://marklodato.github.com/visual-git-guide/index-en.html
posted by Phredward at 1:19 PM on July 8, 2012 [2 favorites]

I've used gitflow to seperate development branches from production. Here are a few relavant links for explaining how to use it properly: A successful Git branching model, and How to use a scalable Git branching model called Gitflow.

Those should get you started, but if you need more search google for the phrase "git branching model" and you should find plenty of
posted by schade at 1:19 PM on July 8, 2012 [1 favorite]

You should make a tag for every deploy version you push to qa/prod, then it's very "reproducible" to push tags as needed.

Others have noted that there may be better branch workflows for you, but I think it's important to have a repository of all your pushed states just in case you need to roll back. No need to manually revert or do fixes when you have all your tags done.
posted by shownomercy at 1:32 PM on July 8, 2012

Regarding live vs. staging servers, I’ve often used a setup where there’s no connection from the original repository to live. On staging I pull from Github and test, then if it works I push to a live repository which knows nothing of Github. It allows for checked-in configurations and local settings that don’t leak to a public repository.

It sounds a bit like you’re building a website with one live version rather than a piece of software that’s distributed and run on different computers. Branches can be a real nightmare in this scenario, and many service developers skip them entirely in favor of feature flags.
posted by migurski at 1:45 PM on July 8, 2012

Yeah, you really want a separate branch for development and testing. I always have "master" and "dev" branches, even for my own stupid little projects that nobody besides me uses.
posted by qxntpqbbbqxl at 3:05 PM on July 8, 2012

Branching is cheap in git, on purpose. So, everything should get a branch. Not just dev/prod/test branches, everything. A bugfix is a branch, a new feature is a branch, performance experiments are a branch, making the logo bigger is a branch, upgrading to a new version of some library dependency or something is a branch. Never work on the master at all-only merge changes from the branches (or rebase instead of merge, there's a cost/benefit with either choice). This will fix both of your problems.

1) You are working on low priority work when suddenly high priority work comes in. No big deal, because the low priority work is on its own branch. Commit whatever you have to the branch, and create a new branch for the high priority work (or checkout the existing branch if applicable).

2) Existing branches are already their own test beds.

You can also start branching from branches-maybe there's a feature in development for a few weeks and you want to merge the latest changes in from the master without disrupting progress if the changes are incompatible. So you branch from the feature branch and merge from the master into the new branch.
posted by Kwine at 5:04 PM on July 8, 2012

Also, my boss was trying to use tortise on Windows for a while and it was awful. I believe that Github has released a better windows client? Someone I know uses that and likes it, I think. I looked around about six months ago and the state of windows GUI clients was grim. You'll be better off in the CLI. I use Tower on the Mac and it does most of what I need it to.
posted by Kwine at 5:08 PM on July 8, 2012

Another thing about branches-for-everything: give them useful, descriptive names and delete them when you’re done with them. I prefer verbs at the beginning of branch names, e.g. “fixing-user-login” or “adding-password-hashes” instead of “user-login” or “password-hashes”. Sentences are a great way to keep your collaborators and future self informed of what you were thinking. When you’ve finished a feature or fixed a bug and merged its branch, get rid of the branch so you can see just the things you’re actually working in a list with `git branch -v`.
posted by migurski at 5:20 PM on July 8, 2012 [1 favorite]

Everybody does git differently, but this is the writeup that made it click for me. I think git flow is overkill and don't branch as much as I feel I should, but it is important to know that commits as well as branches are cheap.

Another thing that's handy if you forget to commit for a while is "git add --patch", which lets you commit only part of your changes. This lets you break up your work into commits in one go.
posted by 23 at 6:16 PM on July 8, 2012

GitHub has indeed released a better windows client.

Personally, I've gone through a few different workflows, and I tend to do most of my gitting using the command-line. I've found a few GUI clients to be helpful, though, especially with visualization.

I see you've already been given the git-flow recommendation. That can work, and it definitely gives you a nice framework (especially if you use the tools built around it), but can also be a bit too much, especially for smaller projects. Really, in the end you want to find what works for you, either personally or with your team. To that end, I suggest checking out the git-scm site and Pro Git.
posted by cardioid at 6:10 AM on July 9, 2012

Caveat: If I'm going to be comparing diffs and selectively choosing which portions to keep and which to discard during the merge process, it does seem that a GUI with highlighting and whatnot would make this much simpler and clearer than on the commandline. So that might be worth keeping in mind, unless I'm wrong wrong wrong.

Check out 'git mergetool' and 'git difftool'. You can actually configure git to launch an external app for your merges and diffs. For example, on my Mac I have git launch Apple's 'opendiff' tool for merges. git's built-in diff is nicely configurable too.

I haven't tried TortoiseGit, but if it's anything like TortoiseSvn it's probably teaching you bad habits. Get used to the command line. The Github for Windows client above looks nice, although I haven't tried it myself. There really is a dearth of good GUI Git apps for Windows.

It does sound like you need to branch a lot more. You also seem a bit worried about merging, which is more painless than it sounds. If you're working by yourself, or your area of the project is fairly separate from others, you should hardly ever have to go through the manual merge process. git-mergetool, once set up to your liking, makes manual merging less painful too.
posted by neckro23 at 9:35 AM on July 9, 2012

For example, several times now I've been working on a feature and then had an unrelated bug that needed fixing. Right now that requires me to do a stupid dance with my commits and deployment that isn't really optimal or sane.

Well, there's git stash, which is pretty reasonable.
posted by pwnguin at 8:06 PM on July 10, 2012