Questions about working with Git

Question

There are a lot of guides on Git commands but I haven't seen many that explain how developers actually use it on a day-to-day basis. I understand the basics of push, pull, commit, etc... but I don't understand when to use branches.

On the local repo:

• Should you create a new branch for every set of changes or is okay to work on the master branch?

• Should you create a new clone for every branch?

• When do you merge your local branches with your local master?

Thanks.

Answer 1

Should you create a new branch for every set of changes or is okay to work on the master branch?

It's a matter of taste. You should create a branch for every major feature you implement ("topic branches"), thus beeing able to do bugfixes on the original master branch. For small projects, it is OK to work on the master branch.

For example, if you plan to do a major redesign, spanning multiple files or working on it over a longer period of time, you should definitely create a topic branch for it. Especially if you plan to use "unstable" commit in between, which is encouraged.

That said, it might be reasonable to work on a different branch most of the time since it might be hard to know in advance how much work a topic will need.

Should you create a new clone for every branch?

No. Why should you? Just create a new branch and use git checkout <branchname> to switch branches.

Hint: Learn about git stash to temporarily "stash away" all local modifications, it is extremely handy when working with branches.

When do you merge your local branches with your local master?

Once the "topic" is finished you should merge it with the master. After that, you may delete the topic branch.

When (and how) do you create a remote branch?

You can specify which local branch to synchronize with which remote branch using git pull, git push or by defining the corresponding refs in the .git/config file.

You need remote branches when you want to share a branch over multiple machines or users.

Answer 2

Should you create a new branch for every set of changes or is okay to work on the master branch?

I create a new branch when I will be doing a number of related changes that I may decide not to keep, but would tear apart and break the master branch while I'm working on them. Especially if I want to make multiple checkins along the way.

For example, let's say that I have a simple graphical calculator application and I want to add parenthesis and order of operations, but I'm not sure whether it'll work the way I'm thinking about doing it. I'd create a new branch, checking in my changes as I go, and if I like the result at the end then I'll merge with Master.

This is especially good if I've got people asking for bugfixes to the released version (built off of master) while I'm working. I can easily switch to master, fix a bug, rebuild, re-release, and switch back to my development branch.

Should you create a new clone for every branch?

I would not suggest creating a new clone for each branch unless you don't want to check local changes in before switching. But even then you can use the "git stash" command to save your changes while you switch branches, do work, and switch back.

When do you merge your local branches with your local master?

You should merge your local changes with the master branch when you are able to build successfully and you think you've implemented the feature you were aiming for. Don't break the master branch.

When(and how) do you create a remote branch?

You create a remote branch by creating a local branch and pushing while you have that local branch checked out. You should only push a new branch to create it remotely if you want a backup of it or if other people may want to check it out. If you are just playing with a feature locally, you probably don't want to push it.

Do you write a message relative to the file you changed or relative to the project?

Relative to the project. Make your commit messages as clear as you can, but try to do write a concise summary line, then leave a blank line, then put details about your commit. Git is tree-based, rather than file-based, so if a feature or bug-fix touched a bunch of files, check them all in at once with the same message.