Git Tips for Beginners Interested in Open Source(markjberger.com)
markjberger.com
Git Tips for Beginners Interested in Open Source
http://markjberger.com/blog/git-tips-for-beginners-interested-in-open-source
9 comments
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.
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).
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).
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.
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.
OP was pretty clear that they were coming from a "collaborating in open source" point of view, I thought.
This has to be the smallest and most important git tip I've read. Suddenly I see branches as transactions and master a coherent backend.
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)
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
[1] https://coderwall.com/p/hh-4ea
This is pretty cool. Thanks for pointing this out!
Personally it seems faster to work with the rebate -i todo list than to search the log for a commit message retype it with "fixup,". And hope I got the message right.
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.
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.
Trunk is normally called origin in git nomenclature.
Pedantically, when you refer to "origin", you're referring to the default branch for the remote named "origin" (i.e. the branch referred to by refs/remotes/origin/HEAD after cloning).
This is typically master, but not necessarily. In fact, you can update refs/remotes/origin/HEAD to point to any branch under refs/remotes/origin via "git remote set-head". (It's also possible that the remote repo's HEAD was something other than master when you cloned.)
If you want to be explicit, use origin/master, or refs/remotes/origin/master to be more explicit still.
The same applies for other remotes you may have configured in the same repo.
A related concept is the @{u}/@{upstream} token. Git resolves this token from the currently checked-out branch's configuration. e.g., if master is checked out (i.e. HEAD is refs/heads/master), git checks in .git/config for branch.master.remote and branch.master.merge and uses those to determine the upstream branch. In this example, those would typically be branch.master.remote=origin and branch.master.merge=refs/heads/master, which git resolves to refs/remotes/origin/master.
Finally, @{upstream} can be configured via git branch --set-upstream-to=... (in older versions of git the more confusing and now deprecated --set-upstream was used).
Pedantically, when you refer to "origin", you're referring to the default branch for the remote named "origin" (i.e. the branch referred to by refs/remotes/origin/HEAD after cloning).
This is typically master, but not necessarily. In fact, you can update refs/remotes/origin/HEAD to point to any branch under refs/remotes/origin via "git remote set-head". (It's also possible that the remote repo's HEAD was something other than master when you cloned.)
If you want to be explicit, use origin/master, or refs/remotes/origin/master to be more explicit still.
The same applies for other remotes you may have configured in the same repo.
A related concept is the @{u}/@{upstream} token. Git resolves this token from the currently checked-out branch's configuration. e.g., if master is checked out (i.e. HEAD is refs/heads/master), git checks in .git/config for branch.master.remote and branch.master.merge and uses those to determine the upstream branch. In this example, those would typically be branch.master.remote=origin and branch.master.merge=refs/heads/master, which git resolves to refs/remotes/origin/master.
Finally, @{upstream} can be configured via git branch --set-upstream-to=... (in older versions of git the more confusing and now deprecated --set-upstream was used).
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.
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.
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.
This is an excellent workflow and then one I use as well.
I use 'upstream' for this purpose.
Agreed, git push -f has caused a lot of grief because of git newbies. So in my workplace its considered a cardinal sin except under some special circumstances. It needs a really big RED box around it.
Special circumstances being the common case of working in your own private branch? Kinda weird to make that big of a deal out of it.
I've generally considered trunk to be "upstream"
"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).
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).
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.
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.
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.
There's a slight difference, I think. Overtime his/her mind will change to get Git better.
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.
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.
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.
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.
This is one way in which 'git send-email' is lighter weight and more convenient, provided all involved know how to use it.
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.
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.
"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.
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.
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
1) No password stored in plain text
2) Still secure without having to enter your password every time
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.
+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.
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.
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)
"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!