|
peepsalot posted:I have a personal fork of an open source project on github (because I'm not an official maintainer of the main project). I made some small changes and did a couple pull requests (which got accepted, yay!) and then I wanted to sync my fork with upstream again. Add upstream as a remote, if you haven't already: git remote add upstream https://github.com/upstream-owner/upstream.git Fetch the latest revisions: git fetch upstream Reset your master branch to match upstream's: git checkout master; git reset --hard upstream/master
|
#
?
Jul 16, 2017 23:13
|
|
|
|
| # ? May 13, 2024 12:18 |
|
|
The standard workflow when contributing to someone else's project is to do your work in a dedicated branch, then submit a PR from your branch to their master. Your master should never diverge.
|
|
#
?
Jul 17, 2017 03:26
|
|
|
I tend to just replace my fork's master with an orphan commit that just says "hi I'm a repo for feature branches" in the readme, but I'm weird like that.
|
|
#
?
Jul 17, 2017 11:04
|
|
|
Ok, I got it worked out. I think the thing I was missing was that I have to force the push to my fork since I had rolled back stuff that was pushed already.Ralith posted:The standard workflow when contributing to someone else's project is to do your work in a dedicated branch, then submit a PR from your branch to their master. Your master should never diverge. I do a code, add, commit, push to my personal fork From github UI, create Pull request for the upstream project Pull Request is accepted and merged by upstream maintainer, and they do another unrelated commit Now my fork is out of date, I try to update my local repo from upstream and I screwed something up here, (I guess I did a pull instead of pull --rebase ? i thought it should have been eligible for auto fast forward though). Anyways its recovered now. So, the above issue was all related to hobby/side project that I contribute to for fun, but I also use git/github for my day job (employer has a private repo). I feel like I could really use some kind of formal training / structured class / seminar or whatever you wanna call it so I can be more effective in using git and waste less hours banging my head against a wall. Also I think that many of my co-workers have roughly the same level of competence with git that I do, so they could also benefit. Is there a service people would recommend that I can tell my boss to sign up for. Like where they bring in a git wizard from a faraway land to teach us to git good? And also maybe talk about branching strategies that are not an absolute clusterfuck?
|
|
#
?
Jul 17, 2017 18:00
|
|
|
Read https://git-scm.com/ . Then read "A successful Git branching model" at http://nvie.com/posts/a-successful-git-branching-model/ to learn how to do branching the hard way. Then learn literally any other model. At least half the popular Git branching models are a reaction against that one. Then form oddly strong opinions on rebase v. merge, and have an argument on "what does a commit represent?" Boom. You're now the Git wizard in the company.
|
|
#
?
Jul 17, 2017 18:50
|
|
|
lifg posted:Read https://git-scm.com/ . Then read "A successful Git branching model" at http://nvie.com/posts/a-successful-git-branching-model/ to learn how to do branching the hard way. Then learn literally any other model. At least half the popular Git branching models are a reaction against that one. Then form oddly strong opinions on rebase v. merge, and have an argument on "what does a commit represent?" And walk through this. http://learngitbranching.js.org/
|
|
#
?
Jul 17, 2017 19:45
|
|
|
I just use this one page as a reference and refuse to learn anything else. http://ohshitgit.com/
|
|
#
?
Jul 17, 2017 19:57
|
|
|
peepsalot posted:Well, here's roughly what went down: Vanadium posted:I tend to just replace my fork's master with an orphan commit that just says "hi I'm a repo for feature branches" in the readme, but I'm weird like that.
|
|
#
?
Jul 19, 2017 00:21
|
|
|
I have a git repo and I create a feature branch called foo. In this foo branch I start hacking away. I add some things, run some tests, add some commits, etc. At some point I've committed to foo working implementations of some things but it's not finished and I have a handful of uncommitted changes that would break everything if I committed them in this state. I also need to leave and do something else so I want to commit these uncommitted files somewhere so that it's all backed up in case my computer dies or whatever. So what I do now is I create a new branch from foo called nightly/foo and commit my changes to there. Now I have foo which is "finished" feature code, and nightly/foo which is unfinished stuff. I push both branches to my Bitbucket repo to get them saved off my computer. The next day I come back and want to keep working on foo. Since I honestly have no idea what I'm doing outside of basic merging and pulling, I just clone the entire repo into a new temporary folder, switch to my nightly/foo branch, and then manually move all the changes files into my original working location under the foo branch and then I just delete this new temporary folder. So uh, just give it to me straight and tell how dumb what I'm doing is and what the proper way to do what I want is because I'd like to learn but whenever I google I get a ton of different answers and I just don't know what to do. e: the reason I don't just switch to nightly/foo and work on it directly and merge back to foo is because well, I dunno. My IDE/git status shows me a list of changed but uncommitted files and this let's me keep track of what I've done. Boris Galerkin fucked around with this message at 09:53 on Jul 19, 2017 |
|
#
?
Jul 19, 2017 09:51
|
|
|
lifg posted:Read https://git-scm.com/ . Then read "A successful Git branching model" at http://nvie.com/posts/a-successful-git-branching-model/ to learn how to do branching the hard way. Then learn literally any other model. At least half the popular Git branching models are a reaction against that one. Then form oddly strong opinions on rebase v. merge, and have an argument on "what does a commit represent?" I use GitFlow. What's a better one? I'm about to start a new project, could be good to know.
|
|
#
?
Jul 19, 2017 10:48
|
|
|
Ralith posted:The github UI is pretty good at communicating what's a fork and what's the upstream repo without any effort on your part. To the point where it's kind of obnoxious to manage the (rare) case where that relationship needs to change. I guess I just don't enjoy having this inert, frozen-in-time branch that everybody lands on by default when people click my fork. It can only confuse people.
|
|
#
?
Jul 19, 2017 11:37
|
|
|
You can change which branch is displayed by default in your repo's GitHub settings.
|
|
#
?
Jul 19, 2017 12:27
|
|
|
chippy posted:I use GitFlow. What's a better one? I'm about to start a new project, could be good to know. There isn't "better", just "appropriate for your needs". Since you already have experience, I say you should try building a branching strategy that works for your testing and deployment requirements. It's sounds dry, but it's actually kinda fun. That said, GitHubFlow is nice and simple.
|
|
#
?
Jul 19, 2017 13:38
|
|
|
Vanadium posted:I guess I just don't enjoy having this inert, frozen-in-time branch that everybody lands on by default when people click my fork. It can only confuse people.
|
|
#
?
Jul 19, 2017 18:28
|
|
|
wolffenstein posted:You can change which branch is displayed by default in your repo's GitHub settings. But there isn't any branch it should display! It's just a bunch of random WIP branches or whatever. Why should one be distinguished from the others?
|
|
#
?
Jul 19, 2017 21:04
|
|
|
Boris Galerkin posted:I have a git repo and I create a feature branch called foo. In this foo branch I start hacking away. I add some things, run some tests, add some commits, etc. I think you can just reset --soft back to where foo is, and then checkout foo. I know you can reset --mixed back to where foo is, unstage everything, and then checkout foo. I don't know the specific command-line incantations because I'm a baby who needs a UI.
|
|
#
?
Jul 20, 2017 02:06
|
|
|
chippy posted:I use GitFlow. What's a better one? I'm about to start a new project, could be good to know. As mentioned, do what you and the people you work with like and agree makes sense for how you work. If that's gitflow, use gitflow. It's got good tool support, it matches well to some people's mental models of how development and deployment should happen. I personally think it's a bit over-complicated, but that's me. If you want a longer anti-gitflow rant then there's of course a gitflow considered harmful, because programmers know how to run a joke into the ground. In general I think that appropriate workflow depends on how familiar a team is with git, how they organize their releases and how they collaborate. A web shop doing a dev/staging/production split might want to reflect that in the repo, a native binary dinosaur has no particular reason to do so but might need a mechanism for platform-specific release branches. A fully remote team probably wants to avoid any workflow that requires non-asynchronous coordination, but if you're in the same office then talking with your peers about git for a minute per week isn't too bad. The team I work in decided to not use gitflow because: - We don't think the persistent develop and hotfix branches add any value for us. - We like to keep a clean commit history, and feel that all the crossing merges and branches in gitflow made history relatively hard to follow. - We want master to be the one branch people branch from and merge to, as well as the source for our nightly builds. Master will occasionally be slightly unstable when someone merges a feature with a bug that slipped through automated testing, and we're OK with that. Other people may have different priorities on all of the above, and that's fine. We went with a workflow where work is done in (ideally) short-lived feature branches on a shared central repository (company github) that are occasionally rebased on master during development and merged through PRs directly to master once approved. People are encouraged to use interactive rebase to clean up their bugfix commits, updates from code review comments, drop temporary debug code and so on prior to their merge. Some good commits on master are tagged as releases as required/on whim, and if we need a hotfix for a particular release we create a hotfix branch on that release tag and cherry-pick bugfix commits from master to create a patch release. It's similar to a lot of stuff discussed in the oneflow by the considered harmful person, mostly because both are patch submission workflows adapted to shared team repos and PRs. Cons: the rebases can require more coordination for long-lived or collaborative feature branches. Our workflow doesn't have any tool enforcement (not that I think we'd use them). Some engineers aren't comfortable with squashing/dropping commits, interactive rebase or history editing in general (we're OK with the new-to-git engineers not doing that stuff, but sometimes people have Strong Opinions about commit history).
|
|
#
?
Jul 20, 2017 09:22
|
|
|
Boris Galerkin posted:I have a git repo and I create a feature branch called foo. In this foo branch I start hacking away. I add some things, run some tests, add some commits, etc. Hah yeah, that's going about it kinda the hard way. Okay never clone your repo unless you're really worried or doing something crazy. That shouldn't be necessary. (I've done crazy things before though lol) In the future if you have some poo poo you need to store but you don't know where to store it right now, you can stash it, then branch, then unstash and then commit the changes. Whenever you're working on something different like that though, try to branch ahead of time and it'll be easier. You can always flip between branches and until you merge them they won't affect each other, and merging is easy. You really want to embrace branching and merging all the time with git. You could also just commit, then walk back to the last commit and branch from it too. Basically you weren't far off just there was no reason to go through the effort of cloning and then copying the files. Just switch branches. Make sure all changes are committed before you switch branches but git will complain to you anyways. You can always use "Git status" to get a list of new files, deleted files, modified files, etc. Its super handy. I use Git Status constantly to keep an eye on things. Wouldn't copying the files screw up your IDE anyways? I guess you swapped the files somewhere else and then moved them back later. That's awkward. If you're using Git you can always do git status and it'll check every file's modified status, and its pretty smart, so just swap branches, use that, check in your changes, and then swap back. Your IDE if it has a git plugin should be able to get the status accurately from that. Every change should be committed. If you end up regretting a change you can easily walk back to a previous commit on that branch. Or you can branch from a previous commit. Commits, branches and merges are all very easy and painless to do with git, so you should use them constantly. Don't be afraid to constantly commit and branch, it isn't a big deal like with CVS.
|
|
#
?
Aug 15, 2017 20:27
|
|
|
Can somebody please explain what happened to me - I'm inexperienced with git so it doesn't really make much sense. I've a local branch A and a branch B. I wanted to merge branch A to B, so: - I checkout branch B - I merge the branch A to B - I push B to server Upon push I pulled, expecting to see that nothing was changed on my local. To my surprise, new files were retrieved from the server, resulting in one conflict, so: - I fix the conflict (same line in both versions for some reason), effectively merging B with B - I push B to server Upon pushing I observer that changes I've done in A and merged into B, are gone. What has happened? The only explanation is that when checking out B, it didn't update it with the most up-to-date version retrieved from the server, so I was actually merging A with B-from-the-past and then when pulling B it overwrote B-from-the-past (is that correct? is there a local cache that is used when you checkout? and in that case, how can I make sure that when checking out, a latest version is retrieved from the server? do i have to do pull after every checkout - that seems superfluous), but that feels... well, weird. At least the new files from B-from-the-past should be retained in B, although to be fair, thinking about it, on the summary of update they might have popped on as removed, as, well, they wouldn't exist in B anymore, though I'd expect it as a conflict. canis minor fucked around with this message at 18:12 on Aug 18, 2017 |
|
#
?
Aug 18, 2017 18:10
|
|
|
canis minor posted:Can somebody please explain what happened to me - I'm inexperienced with git so it doesn't really make much sense. The push to B should have failed because it would not have been a fast forward operation, if B on the server (origin/B) had been independently updated and then you tried to push to it. Are you sure your initial push actually succeeded? Git's model of local and remote branches is frequently a source of confusion when it comes to how fetch/pull/push behavior works. When you do git pull, what Git is really doing is doing git fetch, which updates the local set of objects, and then git merge, which performs a merge with the remote that your current local branch is pointing to as its upstream. It does not automatically merge any other local branches with their remotes, which seems to be what confuses people. What it sounds like happened is your B and origin/B diverged in history because somebody else was doing things on their own copy of B and then pushed them to origin/B. You made your own changes to B without pulling first, pushed, maybe didn't notice that the push failed, pulled, and Git merged the current state of origin/B with your B (hence the merge conflict). As far as your last statement about the changes disappearing when you pushed again, Git will not allow anything but a fast-forward when pushing unless you specify --force, which will ruthlessly clobber the state of the remote ref, or --force-with-lease, which will ruthlessly clobber the state of the remote ref if nobody else has pushed things to it since the last time you did. If the changes disappeared, it sounds like the remote got force-pushed by somebody else to overwrite what you did or there's a repo hook that unwound your changes for some reason (e.g. a hook to reject merge commits).
|
|
#
?
Aug 18, 2017 18:39
|
|
|
chutwig posted:The push to B should have failed because it would not have been a fast forward operation, if B on the server (origin/B) had been independently updated and then you tried to push to it. Are you sure your initial push actually succeeded? I'm using TortoiseGit with default checkboxes ticked, and nowhere I've checked force, or fast-forward (I don't remember fast-forward, but force is there, and it definitelly wasn't checked). Yes, the initial push has succeeded. I had checked out B in the past, but after checking out again (to do the merge), I'd think that it should automatically update with all the changes from the server. I've not done any changes on B on my local, if that makes a difference. The conflict was a weird one, as it was the same line, with same content in both versions. The changes disappeared from my local machine - so I'm fairly sure that's not it. There's no harm done, as all the changes I've done were still in A, so what I had to do afterwards was merge them again into B, but I want to make sure for it not to happen again, since my question: when checking out does git automatically update the local code with what is in the repo, or do I have to pull after checkout?
|
|
#
?
Aug 18, 2017 20:20
|
|
|
canis minor posted:when checking out does git automatically update the local code with what is in the repo, or do I have to pull after checkout? If you are checking out an existing local ref, Git will not update it automatically and you need to do a pull to bring your local ref up to the same place as the remote ref.
|
|
#
?
Aug 18, 2017 21:35
|
|
|
Thank you - I think that confirms my observations, though it still strikes me as odd behaviour. Oh well - I'll pull after every checkout from now on then.
|
|
#
?
Aug 18, 2017 22:08
|
|
|
It's the entire design philosophy of git and other dvcs: everything is local until you explicitly do something with a remote.
|
|
#
?
Aug 19, 2017 09:35
|
|
|
Am I the only git user who never, ever pulls? I always only fetch and then do my own merging.
|
|
#
?
Aug 19, 2017 20:45
|
|
|
raminasi posted:Am I the only git user who never, ever pulls? I always only fetch and then do my own merging. Only because technically git remote update whilst doing the same thing has different intermediate stages.
|
|
#
?
Aug 19, 2017 21:28
|
|
only
|
I always pull and expect it to do a ff-merge, or reset --hard origin/foo. 
|
|
#
?
Aug 20, 2017 11:05
|
|
|
git pull --rebase here.
|
|
#
?
Aug 20, 2017 12:19
|
|
|
I've been moved to a team that--for reasons not in our control--uses TFS 2010 with TFVC. So I'm having to learn best practices there until some future point where we can upgrade TFS to at least 2013 and consider using Git for VC. Right now we each have our own development branch (Development-Ciaphas for example), and Main. When we want to merge to Main, we: -Merge from Main to our branch, resolving conflicts -Check in, using some suitably pithy checkin comment like "Merge from Main" -Merge from our branch to Main (should be 0 conflicts) -Check in using another pithy comment So my questions: 1) Do we need to do Get Latest at any point in those steps? 2) Is this even remotely like a best practice for a small team of 4 developers? 3) I don't know my way around the TFS gui in Visual Studio. When I look at the checkin history on Main, I just end up with a lot of "Merge from Development-XXX" checkins. How do I trail this back to the relevant checkins in the relevant branches?
|
|
#
?
Aug 25, 2017 20:23
|
|
|
Ciaphas posted:I've been moved to a team that--for reasons not in our control--uses TFS 2010 with TFVC. So I'm having to learn best practices there until some future point where we can upgrade TFS to at least 2013 and consider using Git for VC. 1) It's always a good idea to get latest before you do any merging operations. I swear it doesn't matter but I've heard enough people complain about bad merges that I'll assume it does. 2) Yeah, that's fine . You should be reverse integrating changes from Main on a regular basis, though. 3) In 2010? Nope. Better branch visualization was added later on but I doubt it's supported in TFS 2010. TFS 2010 was EOLed several years ago and is unsupported. Getting to a modern version is going to suck for you guys. You'll have to do 2010 -> 2012, then 2012 should upgrade cleanly all the way to 2017. But 2012 doesn't support modern SQL server versions and 2017 only supports modern SQL server versions. There is zero reason to upgrade to anything other than the latest since the downtime and complexity of upgrading is going to be roughly the same whether you're going from 2010 to 2013 or 2010 to 2017. Among other things, TFS upgrades are one of the things I do professionally (albeit rarely). Get upgraded to 2017 Update 2 as soon as possible and import it to VS Team Services and never have to deal with upgrade pain again. Seriously. Or if you're not using the work item tracking stuff, just use Git-TFS to convert the TFVC repo to a Git repo and shove that into VSTS. New Yorp New Yorp fucked around with this message at 20:41 on Aug 25, 2017 |
|
#
?
Aug 25, 2017 20:39
|
|
|
New Yorp New Yorp posted:1) It's always a good idea to get latest before you do any merging operations. I swear it doesn't matter but I've heard enough people complain about bad merges that I'll assume it does. We're early enough in the project that simply taking a current snapshot of the solution and wholesaling it over to a new/updated VC package isn't wholly incorrigible to the team leads/management. So we may just uninstall 2010 entirely and install 2017 on top, if it comes to that (we're on VS2015 but the main stakeholders all have MSDN licenses so VS2017 shouldn't be long in coming). The network in question is air-gapped off of the internet for security though, and for the same reason getting approval for software upgrades is a pain in the rear end, so it might take a while, and VS Team Services is obviously OBE 
Ciaphas fucked around with this message at 20:49 on Aug 25, 2017 |
|
#
?
Aug 25, 2017 20:47
|
|
|
Ciaphas posted:We're early enough in the project that simply taking a current snapshot of the solution and wholesaling it over to a new VC solution isn't wholly incorrigible to the team leads/management. So we may just uninstall 2010 entirely and install 2017 on top, if it comes to that (we're on VS2015 but the main stakeholders all have MSDN licenses so VS2017 shouldn't be long in coming). That's reasonable. If you're not using it for anything other than source control and you want to move to Git anyway, just Git-TFS the repo and do a clean install of TFS 2017.2. But if you're not using any of the features beyond source control, there's really zero reason to use TFS in the first place.
|
|
#
?
Aug 25, 2017 20:51
|
|
|
New Yorp New Yorp posted:That's reasonable. If you're not using it for anything other than source control and you want to move to Git anyway, just Git-TFS the repo and do a clean install of TFS 2017.2. But if you're not using any of the features beyond source control, there's really zero reason to use TFS in the first place. Some of the team members are making inroads on build automation and alerting, but no one would die if everything but the current VS solution disappeared. We're all just programmers, none of us are proper administrators. I'll bring up that maybe TFS can be dumped entirely. I believe at the time it was set up it was considered to be the best option for Windows-based version control. But I would like to be able to set up alerting and automatic builds on checkin to Main, at least, and I'm not sure Git on its own can support that.
|
|
#
?
Aug 25, 2017 20:55
|
|
|
Ciaphas posted:Some of the team members are making inroads on build automation and alerting, but no one would die if everything but the current VS solution disappeared. We're all just programmers, none of us are proper administrators. That's a good reason to stick with it, then. But hold off on build automation until you're using TFS 2017. A modern build system that doesn't horribly suck was introduced in TFS 2015 and there is no forward compatibility with the TFS 2010 XAML build system.
|
|
#
?
Aug 25, 2017 20:58
|
|
|
New Yorp New Yorp posted:That's a good reason to stick with it, then. But hold off on build automation until you're using TFS 2017. A modern build system that doesn't horribly suck was introduced in TFS 2015 and there is no forward compatibility with the TFS 2010 XAML build system. Will do, thanks. Talked again with my team lead about it, demonstrated that it's difficult/impossible to trail merge changesets back to their constituent branch changesets, and he said (and I quote) "That's retarded, why didn't anyone notice this before?" (He's new to the post too--big old shakeup.) So hopefully soon the paperwork for an upgrade to TFS will be submitted and we can re-evaluate TFVC vs Git at that point. He did ask, however, if it would be possible to somehow export the changesets and their comments--for what little they were worth, he admitted--out of TFVC 2010, uninstall 2010, install 2017, and re-import them into either TFVC or Git. Any thoughts? Ciaphas fucked around with this message at 22:30 on Aug 25, 2017 |
|
#
?
Aug 25, 2017 22:26
|
|
|
Ciaphas posted:Will do, thanks. Talked again with my team lead about it, demonstrated that it's difficult/impossible to trail merge changesets back to their constituent branch changesets, and he said (and I quote) "That's retarded, why didn't anyone notice this before?" (He's new to the post too--big old shakeup.) So hopefully soon the paperwork for an upgrade to TFS will be submitted and we can re-evaluate TFVC vs Git at that point. Yeah, use Git-TFS. Git-TFS is two-way -- you can have it suck in TFVC changesets, turn them into a Git repo, then either use the Git repo as-is or point it to a different TFVC repo and have it turn the Git commits back into changesets. [advertisement] If your company has a budget and wants some expert assistance, PM me. Otherwise, ask here and get it for free, I guess.
|
|
#
?
Aug 25, 2017 23:30
|
|
|
Ciaphas posted:I'll bring up that maybe TFS can be dumped entirely. I believe at the time it was set up it was considered to be the best option for Windows-based version control. But I would like to be able to set up alerting and automatic builds on checkin to Main, at least, and I'm not sure Git on its own can support that.
|
|
#
?
Aug 26, 2017 02:09
|
|
|
New Yorp New Yorp posted:That's a good reason to stick with it, then. But hold off on build automation until you're using TFS 2017. A modern build system that doesn't horribly suck was introduced in TFS 2015 and there is no forward compatibility with the TFS 2010 XAML build system. We went through a 2012 -> 2015 upgrade. We used git-tf to migrate source with history and then created new builds. It's not awful, but it does take time. The benefits are totally worth it after you start getting up to speed.
|
|
#
?
Aug 26, 2017 02:43
|
|
|
New Yorp New Yorp posted:Yeah, use Git-TFS. Git-TFS is two-way -- you can have it suck in TFVC changesets, turn them into a Git repo, then either use the Git repo as-is or point it to a different TFVC repo and have it turn the Git commits back into changesets. And Git-TFS can work on TFS 2010 one way and TFS 2017 the other way? That sounds too good to be true. (And thanks for the free advice  )Ralith posted:You should be able to set up git hooks to do whatever you want, with sufficient elbow grease. Or use one of the numerous off-the-shelf systems that have such features built in. In my old group on a Linux server I had Git set up to send an email out on a push to master, but figuring out how to automatically perform a test build and detect failure was beyond me.
|
|
#
?
Aug 26, 2017 04:24
|
|
|
|
| # ? May 13, 2024 12:18 |
|
|
Ciaphas posted:In my old group on a Linux server I had Git set up to send an email out on a push to master, but figuring out how to automatically perform a test build and detect failure was beyond me.
|
|
#
?
Aug 26, 2017 06:27
|
|