
Git Tips for Beginners Interested in Open Source - markberger
http://markjberger.com/blog/git-tips-for-beginners-interested-in-open-source
======
sandyarmstrong
"Never Work on Master" \- yes!

"Updating Master to Reflect Trunk" \- (ignoring the "trunk" misnomer, that's
been addressed by other comments). I've recently started taking a step to make
this relatively unnecessary. I delete my local master branch. It has made my
workflow a lot cleaner!

(a) I never accidentally work on master anymore.

(b) I never have to switch to master to pull the latest from the remote.

(c) One less thing to keep in sync and clutter my repo.

Basically, I can now just do `git fetch origin` periodically to get updates
from the remote, and then anytime I want to rebase or make a new branch or
whatever, I refer to origin/master instead of master. And you can always `git
checkout origin/master` if you want. It's the best!

~~~
vsbuffalo
Isn't it more reasonable to say "never work on master if you're
collaborating". If I use Git to manage a single script that only I work on, I
don't see the need to create a branch.

~~~
jlgreco
More reasonable is to say "never expect other people to accept your changes to
master".

Even if you are collaborating, feel free to work on master. You just may
(probably will) have to knock it over to another branch when it comes time to
give it to other people. Think of it like rewriting history with rebase before
you push; the objective is to make it look like you did everything 'correctly'
the first time through.

Branches are a 'weaker' concept in git than some people seem to think. They
are really just labels for commits that can be moved (unlike tags).

~~~
sandyarmstrong
Sure. You can totally work on master. But I find that it's a lot easier to get
confused about what's been merged, and to accidentally make mistakes, when you
make a habit of working on master.

That's why I find that I make a lot fewer silly mistakes if I just get rid of
the local master branch for any repo that I am actively contributing to in a
team environment.

------
emillon
If you use "git rebase -i" a lot, you should give the "autosquash" option a
try. Basically, it enables "commit --fixup <commit>" that will display the
commits in the correct order the next time you rebase. (A bit hard to explain,
sorry)

~~~
ollysb
That's going to be really useful for my workflow. I found this explanation[1]
of how it works pretty decent.

[1] [https://coderwall.com/p/hh-4ea](https://coderwall.com/p/hh-4ea)

~~~
markberger
This is pretty cool. Thanks for pointing this out!

------
richardwhiuk
Trunk is normally called origin in git nomenclature.

git push -f needs a big red box round it, not as a normal thing to do.

If you want to fix a pushed commit, do a new commit! If you keep pushing dodgy
commits, try waiting between committing and pushing, or get better at
reviewing your changes.

~~~
markberger
Thanks for the comments Richard. Since Github uses origin as user's fork of
the project, I was trying to distinguish the project's main repository and the
user's fork. Admittedly, after seeing comments from other people, trunk
probably isn't the best name for it.

~~~
lambda
My convention is usually to clone from the upstream project, thus it winds up
being "origin", and then adding my own repository as another remote, named
after my username. If there are any other users whose repositories I'm
following, I add theirs as other remotes named after their usernames as well,
remaining consistent.

That way, when I pull from origin, I'm pulling from whatever the official
origin repository is; when I pull from another named repo, it's named after
whose repo it is.

It's also frequently the case that I've cloned from upstream before ever
forking the repo on GitHub. It's only once I have any changes I need to make
that I create a fork and add my own remote.

~~~
js2
This is an excellent workflow and then one I use as well.

------
alessioalex
"If you fork a repository on Github, clone the repository with the ssh link.
Otherwise, you will have to authenticate with Github each time you push a
branch."

That's false. The credentials are cached after the first time you type them
in, provided you are using a new enough version of Git ( >= 1.8.3 I believe).

------
talles
Not necessarily for 'Interested in Open Source', seems like tips to anyone who
isn't using a repo alone.

I don't get it the part 'Updating Master to Reflect Trunk'. What is trunk? I
remember trunk from the SVN days (trunk, tag, branches) but nowadays with git
I don't see this terminology anymore. Comparing to SVN trunk is the master
branch. Maybe I missed something, but I don't get it this trunk remote.

Also I would put a more _flashy_ warning on amending something that is already
pushed.

~~~
jtreminio
This is coming from an SVN user who is using Git, not a Git user that's
providing tips to SVN users.

There's a slight difference, I think. Overtime his/her mind will change to get
Git better.

------
oilytheotter
Using rebase relative to HEAD can be tricky, and as others have mentioned,
force pushing a branch is not usually a good idea.

When you are ready to submit a pull request, instead of rebasing the branch
you have already pushed to origin, create a new branch called
your_branch_name-final (I usually call the original branch -wip for for work
in progress). Then, before pushing this branch to origin, run git rebase -i
upstream/master.

------
ianstallings
I wish he would add one more since he mentioned github - don't _fork_ unless
you actually need to. I see way too many forks of projects on github with no
significant changes. If you have a bug fix make it on the same repo and then
submit a pull request with your changes. Forks are for adding new features,
making major changes, or if the original author is no longer maintaining the
project.

~~~
jedbrown
How do you "make it on the same repo and then submit a pull request" without
either (a) having write access to that repo or (b) forking?

This is one way in which 'git send-email' is lighter weight and more
convenient, provided all involved know how to use it.

~~~
ianstallings
Jesus you're right I always use the community model where one can be added to
the project and submit the changes that way. I wish there was an easier way to
use the proper branching model because that's what it truly is, a branch.

That's not even really my beef, it's users that fork and never intend on
making any changes because they don't understand how to clone. So when you
search the name of the project you get a ton of results.

------
aikinai
"Otherwise, you will have to authenticate with Github each time you push a
branch."

It is possible to easily automate HTTP authentication in git by including the
credentials on a .netrc file in your home directory. It should look something
like:

machine example.com login username_here password password_here

Of course it's unfortunate that you have to have your password in plain text,
but it works.

~~~
bradleyland
SSH keys and SSH agent are intended to solve the _exact_ scenario in your
caveat :)

1) No password stored in plain text

2) Still secure without having to enter your password every time

~~~
aikinai
Of course SSH is better all around, but the article was saying that you'd have
to authenticate every time you push if you use the HTTP link which isn't
really true.

------
duggieawesome
+1 for checking trailing white space.

Whenever I'm working on an OS project and I happen to open a file with white
space or unnecessary blank lines, I delete them and send them the changes with
my PR. Highly suggest it.

~~~
elasticdog
It annoys me too. If you do a git diff against the sha1 of a completely empty
tree, you can see all of the whitespace errors that have been checked into a
repository:

    
    
        $ git diff --check $(git hash-object -t tree /dev/null)
    

...although many projects frown upon whitespace-only commits since they screw
with `git blame`.

