6 ms·

Git Tips for Beginners Interested in Open Source

60 points by markberger 13y ago

talles 13y ago
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 13y ago
  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.
richardwhiuk 13y ago
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.
- culp 13y ago
  I've generally considered trunk to be "upstream"
- markberger 13y ago
  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.
  - steveklabnik 13y ago
    I use 'upstream' for this purpose.
  - lambda 13y ago
    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 13y ago
      This is an excellent workflow and then one I use as well.
- mataug 13y ago
  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.
  - ulisesrmzroche 13y ago
    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.
- js2 13y ago
  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).
emillon 13y ago
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 13y ago
  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 13y ago
    This is pretty cool. Thanks for pointing this out!
- DigitalJack 13y ago
  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.
duggieawesome 13y ago
+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 13y ago
  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`.
alessioalex 13y ago
"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).
oilytheotter 13y ago
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.
sandyarmstrong 13y ago
"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 13y ago
  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 13y ago
    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 13y ago
      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.
aikinai 13y ago
"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 13y ago
  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 13y ago
    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.
ianstallings 13y ago
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 13y ago
  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 13y ago
    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.

60 points by markberger 13y ago

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 13y ago
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.

richardwhiuk 13y ago

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.

culp 13y ago
I've generally considered trunk to be "upstream"
markberger 13y ago
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.
- steveklabnik 13y ago
  I use 'upstream' for this purpose.
- lambda 13y ago
  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 13y ago
    This is an excellent workflow and then one I use as well.
mataug 13y ago
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.
- ulisesrmzroche 13y ago
  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.
js2 13y ago
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).

emillon 13y ago

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 13y ago
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 13y ago
  This is pretty cool. Thanks for pointing this out!
DigitalJack 13y ago
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.

duggieawesome 13y ago

+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 13y ago
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`.

alessioalex 13y ago

"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).

oilytheotter 13y ago

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.

sandyarmstrong 13y ago

"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 13y ago
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 13y ago
  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 13y ago
    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.

aikinai 13y ago

"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 13y ago
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 13y ago
  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.

ianstallings 13y ago

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 13y ago
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 13y ago
  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.